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Preface 


The  purpose  of  this  study  was  to  determine  the 
effectiveness  of  standard  PC  software  acquisition  practices 
in  Air  Force  Organizations,  and  to  see  if  better  methods 
could  be  developed.  This  study  was  necessary  in  light  of 
the  wide  use  of  PCs  in  the  Air  Force  today.  The  methods 
proposed  may  assist  organizations  in  choosing  the  right 
software  for  the  right  task. 

Thirty  people  in  four  organizations  were  interviewed  to 
develop  the  proposed  requirements  analysis  model  in  this 
study.  Although  the  small  sample  size  limits  the 
applicability  of  the  proposed  model  to  similar 
organizations,  the  strategies  and  methods  used  in 
approaching  the  software  solutions  may  offer  great  potential 
for  cost  savings  and  positive  results. 

This  Study  could  not  have  been  possible  without  the 
advice  and  guidance  of  my  faculty  advisor,  LtCol  Richard 
Peschke.  Thank  you  sir,  for  your  patience,  assistance,  and 
positive  support  during  this  project.  I  wish,  also,  to 
express  my  appreciation  to  my  other  advisor,  Beverly  Handy, 
for  the  time  and  energy  she  provided  in  making  this  study 
valid.  A  wife,  a  friend,  and  a  critical  reviewer  all  in  one 
person,  you  were  always  there  for  encouragement,  love,  and 
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coffee  on  those  long  nights. 
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Abstract 

The  purpose  of  this  study  was  to  determine  how  Air  Force 
Organizations  selected  Personal  Computer  (PC)  software,  to 
determine  the  effectiveness  of  standard  PC  software 
acquisition  practices,  and  to  determine  if  better  methods 
could  be  developed.  The  study  had  three  basic  objectives: 

1.  Determining  whether  or  not  a  uniform  set  of  PC 
software  selection  criteria  at  base  level  existed. 

2.  Determining  how  effective  the  existing  methods  of 
selecting  PC  software  were. 

3.  Determining  what  additional  factors  organizations 
should  evaluate  before  acquiring  PC  software. 

• 

Analysis  of  interviews  with  thirty  managers  and  users 
from  four  Air  Force  organizations  resolved  that  while  a 
normative  or  regulatory  approach  existed  for  determining  PC 
software  requirements,  the  guidance  was  not  clear  in  helping 
users  select  the  appropriate  software  for  automated  office 
tasks.  As  a  remedy  for  the  lack  of  sufficient  guidance, 
organizations  chose  to  select  software  first  and  then  find  a 
need  to  fit  the  software.  Data  suggested,  however,  that  at 
times  this  resulted  in  less  than  optimum  use  of  the 
software . 

A  requirements  analysis  model  was  necessary  to 
specifically  provide  users  with  a  means  of  categorizing 
their  information  systems  requirements  into  knowledge  work 
tasks,  and  to  select  software  designed  to  satisfy  the 


ix 


identified  knowledge  work.  The  model,  developed  using  tasks 
identified  by  the  interview  respondents  and  literature 
available  on  the  subjects  of  management  information  system 
design,  user  involvement,  and  requirements  analysis 
techniques,  is  presented  and  offered  as  a  solution  to  the 
current  problem. 
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A  REQUIREMENTS  ANALYSIS  MODEL  FOR  SELECTION  OF 
PERSONAL  COMPUTER  (PC)  SOFTWARE  IN 
AIR  FORCE  ORGANIZATIONS 


I.  INTRODUCTION 


Overview 

This  chapter  discusses  the  methods  by  which  information 
systems  requirements  are  determined  within  United  States  Air 
Force  organizations.  Next,  the  purpose  of  the  research  is 
detailed  as  well  as  a  definition  of  terms,  the 
justification,  and  scope  of  study.  Finally,  the  specific 
research  objectives  and  research  questions  are  identified. 
Background 

Of  the  nearly  500  thousand  personal  computers  (PCs) 
purchased  by  the  federal  government,  22%  belong  to  the 
Department  of  the  Air  Force  (20:89).  In  light  of  a 
decreasing  technical  labor  force,  organizations  have  rapidly 
acquired  these  inexpensive  systems  in  an  attempt  to 
streamline  information  processing  and  continue  to  accomplish 
their  missions  (20:89).  While  research  on  the  impact  of  the 
PC  based  management  information  systems  in  Air  Force  offices 
is  limited,  current  studies  suggest  two  problems.  First, 
the  rapid  acquisition  without  proper  planning  has  often 
rendered  some  systems  ineffective  (22,  19:1,  5:170,  14:322). 
Second,  the  improper  planning  often  resulted  in  passive 
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acceptance  of  new  systems  by  intended  users  (23,  19:6, 

5:171).  While  acquisition  and  implementation  of  PCs  has 

impacted  office  efficiency,  productivity  and  time 

management,  the  unplanned  approach  used  in  acquiring  the 

systems  necessary  for  office  automation  may  have  also 

lessened  the  cost  effectiveness  of  these  programs  (9:1).  In 

addition,  several  factors,  when  not  adequately  addressed, 

tend  to  increase  system  life  cycle  costs  despite  their 

relatively  low  acquisition  costs.  These  drivers  include 

inadequate  information  analysis,  limited  information 

handling  systems,  poor  systems  development  processes,  and 

the  operation  and  maintenance  costs  of  the  systems  (22).  At 

the  1988  Executive  Seminar  on  Communications  and  Computers 

in  Air  Force  Systems  Command,  the  following  problems  and 

factors  were  brought  to  surface: 

The  problem  stems  from  the  lack  of  a  cohesive  framework 
and  planning  road  map  to  guide  Air  Force  information 
system  design,  acquisition,  and  implementation.  The  key 
factors  affecting  this  lack  of  cohesion  are  the 
technology  explosion,  the  exponential  growth  in  user 
requirements,  ill  defined  requirements  and  technical 
solutions,  and  a  difficulty  in  focusing  programs  on 
mission  needs.  The  result  has  been  a  proliferation  of 
incompatible  stand-alone  systems,  mission  support 
deficiencies,  a  duplication  of  effort,  a  waste  of 
resources  and  a  loss  of  credibility  [22J. 

To  prevent  a  continuation  of  this  haphazard  approach  to 

the  acquisition  of  PCs,  a  requirements  analysis  model  should 

be  available  to  assist  organizations  in  1)  determining 

information  system  needs,  2)  planning  for  the  system 
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implementation,  and  3)  actually  using  the  systems 
efficiently  and  cost  effectively. 

Two  Air  Force  publications  which  address  Personal 
Computer  requirements,  AFR  700-26  (Acquisition  and 
Management  of  Small  Computers)  and  AFP  700-30  (How  to 
Determine  and  Justify  Information  Systems  Requirements  in  an 
Office  Environment)  currently  offer  some  assistance  to  users 
in  determining  PC  requirements.  Notably,  both  regulations 
recommend  system  development  techniques  and  user  involvement 
during  analysis,  but  leave  considerable  room  for  individual 
development.  Specifically,  AFR  700-26  details  the  PC 
hardware/software  acquisition  process,  but  does  not  provide 
users  with  an  analysis  through  which  they  could  define  their 
office  automation  needs.  While  AFP  700-30  provides 
organizations  and  users  with  a  method  of  identifying 
candidate  areas  for  automation  (through  the  use  of  a  top- 
down  structured  analysis  technique),  this  publication  stops 
short  of  mapping  out  the  appropriate  equipment  for  each 
critical  task  (consultation  with  the  local  communications 
squadron/staff  element  is  suggested  for  determination  of  the 
exact  equipment).  Thus,  while  one  publication  is  designed 
to  help  organizations  acquire  the  PC’s,  the  other 
publication  is  developed  to  assist  the  same  organizations  in 
determining  areas  where  PCs  could  be  used  for  streamlining 
tasks.  Neither  document,  however,  provides  guidance  on  the 
critical  problems  of  identifying  the  specific  hardware  and 
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software.  Thus,  a  requirements  analysis  model  for  matching 
information  systems  with  stated  requirements  (PC  hardware, 
software,  configuration  and  operations)  has  not  been 
designed.  The  task  of  developing  a  working  model  for  Air 
Force  offices  has  yet  to  be  undertaken. 

Purpose  of  this  Study 

General  Issue.  Since  the  early  part  of  this  decade,  Air 
Force  organizations  have  been  instructed  to  streamline 
operations  and  increase  productivity.  One  of  the  ways  to 
accomplish  this  has  been  through  automation  of  critical 
tasks.  For  many  offices,  time  consuming  tasks  have  been 
simplified  through  the  use  of  Personal  Computers.  However, 
no  requirements  analysis  techniques  for  determining  the 
optimum  level  of  PC  automation  that  these  organizations  need 
exists.  A  requirements  analysis  model  should  be  developed 
to  help  organizations  decide  the  following:  1)  How  many 
PC's  do  they  need;  2)  How  large  should  they  be;  and  3)  What 
type  of  software  do  they  need  to  efficiently  streamline 
operations?  The  key  issue  is  this:  "How  can  units  define 
their  office  information  system  needs  for  PC  hardware,  and 
similarly,  PC  software?"  This  study  addressed  the  latter 
part  of  the  question  by  examining  existing  methods  of  PC 
software  procurement.  In  addition,  a  model  to  define  PC 
software  requirements  within  an  Air  Force  organization  was 
developed . 
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Specific  Problem.  How  can  Air  Force  organizations  define 
their  PC  software  requirements?  How  effective  is  the 
existing  method  of  acquiring  PC  software? 

Justification 

Communications  and  Computer  Systems  staff  offices  are 
availabe  to  assist  organizations  in  1 )  identifying 
information  systems  requirements  and  2)  developing  technical 
solutions  to  meet  those  requirements.  However,  for  PCs  in 
particular  (versus  mainframes),  users  are  often  called  upon 
to  state  and  justify  their  own  requirements  for  PC  hardware 
and  software.  Current  guidance  on  PC  hardware  and  software 
selection  is  limited.  This  study  addresses  a  portion  of  the 
overall  problem  by  attempting  to  model  the  PC  software 
selection  process.  Currently,  the  Air  Force  has  been  using 
Small  Computer  Technical  Centers  (SCTCs)  to  manage  software 
libraries  within  each  Major  Command.  The  SCTCs  distribute 
catalogs  of  commercial  and  user  developed  software  programs 
that  are  available  to  Air  Force  personel.  In  addition,  they 
provide  government  owned/licensed  software  to  users  on 
request.  However,  users  have  not  been  able  to  ascertain 
which  specific  programs  are  needed  to  accomplish  the  mission 
at  the  least  cost.  As  a  result,  expensive  programs  may  have 
been  acquired,  but  seldom  used  to  the  optimum  extent. 
Positive  results  from  this  study  should  reduce  the  cost  of 
PC  software  selection  by  insuring  the  right  product  for  the 


stated  requirement. 


Def initions 


1.  Application  Software  -  Computer  programs  which 
accomplish  user  requirements.  They  can  be  general- 
purpose,  commercial,  vendor-supplied,  or  they  can  be 
programs  specifically  developed  by  users  for  unique 
problems.  Examples  of  application  software  include 
word  processors,  data  base  management  systems,  and 
spreadsheets  [8:6]. 

2.  End-User  -  The  principal  user  of  a  computer  system's 
output  products  [15:337], 

3.  Information  Systems  Requirements  Analysis  (ISRA)  -  A 
step-by-step  method  used  to  help  an  organization 
identify  ways  to  improve  the  operational  mission.  By 
using  ISRA  an  organization  can  identify  ways  to 
increase  the  probability  of  operational  mission 
success  and  decrease  the  cost  of  mission  support  by 
better  information  management  [9:1]. 

4.  Knowledge  Work  -  Tasks  which  involve  thinking, 
processing  information,  or  formulating  analyses, 
recommendations  and  procedures.  Knowledge  work 
activities  may  also  include  the  following: 

Diagnosis  and  problem  finding 
Communication 

Planning  and  decision  making 
System  development 
Monitoring  and  control 
Authoring  and  Presentation 
Organizing  and  scheduling  [7:409]. 

5.  Operating  System  Software  -  Programs  which  operate  a 
computer  hardware’s  basic  system  functions  such  as; 
providing  basic  input  and  output  routines,  file 
maintenance  procedures,  and  system  controls  [8:6]. 

6.  Personal/Small  Computer  -  A  specific  class  of 
equipment  to  include  associated  peripherals  and 
software.  It  will  be  the  primary  end-user  device 
for  connection  to  networks  as  well  as  providing 
stand-alone  processing  capability.  It  has  the 
capacity  to  execute  various  software  programs  and 
usually  consists  of  at  least  a  keyboard,  disk  drive, 
visual  display  device,  and  central  processing  unit 
with  random  access  and  read-only  memory  [8:3]. 

7.  Requirement  -  A  need  for  a  new  or  improved 
information  processing  capability  which  when 
satisfied  will  result  in  an  increase  in  the 
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probability  of  operational  mission  success  or  a 
decrease  in  the  cost  of  mission  support  [9:1]. 

8.  Software  Product  -  Software  which  can  be  specified 
by  nane(  such  as  DBASE  111+,  Lotus  123,  or  Word 
Perfect . 

9.  Software  Type  -  Categories  which  software  products 
may  fall  into,  such  as  communications  packages, 
graphics  packages,  database  management  systems, 
spreadsheets,  or  word  processors. 

10.  Standard  Personal/Small  Computer  -  PC  Computer 
resources  acquired  from  an  Air  Force-wide 
requirements  contract  [8:3]. 

1 1 .  Systems  for  Command.  Control.  Communications  and 
Computers  Requirements  Document  (SCRD)  -  The 
document  which  specifies  the  required  automated 
capability,  justifies  the  need,  identifies  available 
resources,  and  serves  as  the  validation  and  approval 
document  for  that  need  [9:1]. 

12.  User  Involvement  -  Participation  in  the  system 
development  by  representatives  of  the  target  user 
group  [ 12  :  586] . 

Assumptions 

1.  All  organizations  use  PCs  compatible  with  the 
systems  listed  on  the  Air  Force  Standard  Small 
Computer  Contract. 

2.  Representatives  in  the  organizations  selected  for 
interview  possessed  the  knowledge  to  answer  specific 
investigative  questions. 

3.  Interviews  were  objectively  conducted  with  minimum 
bias . 

Research  Objectives 

In  order  to  develop  an  effective  PC  software  requirements 
analysis  model,  the  following  tasks  were  pursued: 

1.  Determination  of  whether  or  not  a  set  of  uniform  PC 
software  selection  criteria  at  base  level  existed. 

2.  Determination  of  how  effective  the  existing  methods 
of  selecting  PC  software  were. 
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3.  Determination  of  what  additional  factors 

organizations  should  evaluate  before  acquiring  PC 
software . 

Research  Questions 

This  study  addressed  the  following  questions  in  support 
of  the  research  objectives: 

1.  What  guidance  do  organizations  receive  when 
purchasing  PC  software? 

2.  What  software  products  are  organizations  currently 
using? 

3.  How  do  organizations  determine  which  software 
products  to  obtain? 

4.  Are  the  software  products  being  used  for  their 
intended  purposes? 

5.  Could  a  different  software  product  have  been  used  to 
accomplish  the  same  task  at  less  cost? 

6.  Which  daily,  mid-range  and  long-range  operations  are 
benefitting  from  the  use  of  the  software? 

7.  How  often  are  individual  software  products  used? 

8.  Who  (by  organizational  position)  uses  the  software? 
Summary 

The  information  presented  thus  far  suggests  that  PC  based 
management  information  systems  requirements  analysis  may 
need  further  refinement.  The  research  objectives  and 
questions  in  this  study  were  developed  to  facilitate  the 
development  of  a  PC  software  requirements  analysis  model. 
They  set  the  framework  for  the  literature  research  as  well 
as  the  methodology  used  to  in  gathering  data.  The  overall 
goal  was  to  discover  whether  adequate  PC  software 
requirements  analysis  methods  were  available  and  in  use,  and 
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if  better  methods  could  be  developed.  The  proceeding 
chapters  support  the  search  for  answers  to  the  above 
concerns . 
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II.  LITERATURE  REVIEW 


The  area  of  personal  computer  systems  requirements 
analysis  is  currently  undefined  to  a  large  extent.  Current 
research  on  management  information  systems,  however,  covers 
a  broad  spectrum  of  analyses  ranging  from  human  factors 
considerations  during  hardware  and  software  design  stages  to 
problems  and  solutions  during  implementation  and  operational 
stages  of  the  systems.  Such  areas  could  be  instrumental  in 
defining  software  requirements  for  PCs  in  an  office 
environment.  In  light  of  these  factors,  this  study  examined 
several  related  areas  in  the  management  information  systems 
(MIS)  requirements  analysis  environment.  These  areas 
included  MIS  requirements  analysis  techniques,  elements  or 
factors  which  may  be  considered  during  system  design,  and 
user  involvement  studies  addressing  systems  implementation 
and  end-user  computing.  Results  of  the  review  follow. 

Requirements  Analysis  Techniques 
Several  methods  for  determining  and  analyzing  MIS 
requirements  exist  in  today’s  environment.  Apparent  in  all 
methods  are  four  strategies,  including  interviewing, 
surveying,  review  of  organizational  structure  to  determine 
the  flow  of  information,  and  direct  observation  (21:65). 

The  following  methods  are  enhancements  and  refinements  to 
these  basic  elements. 
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Data  Flow  Analysis.  Data  flow  analysis  is  a  technique 
used  to  show  the  flow  of  information  pictorially  (21:112). 
This  allows  designers  and  users  to  clarify  steps  in  the 
information  flow  as  well  as  the  decision  making  process. 
Specific  steps  in  the  data  flow  analysis  strategy  include: 

1.  Study  operations  and  ongoing  processes. 

2.  Identify  how  data  is  processed  in  handling 
transactions  and  completing  tasks. 

3.  Follow  the  flow  of  data  from  input,  processing, 
■through  storage,  retrieval  and  output. 

4.  Gradually  add  details  at  lower  levels  (21:112). 

The  benefits  of  data  flow  analysis  are  1 )  the  way  in 

which  data  is  pictorially  defined  and  2)  the  use  of  diagrams 
for  showing  interactions  between  elements  involved  in  the 
information  or  decision  process. 

Structured  Analysis  and  Design  Technique  ( SADT ) .  A  more 
detailed  method  of  determining  requirements,  SADT  "consists 
of  both  techniques  for  performing  systems  analysis  and 
design  and  a  process  for  applying  theses  techniques  which 
significantly  increases  the  productivity  of  a  team  of 
analysts"  (24:1-1).  A  diagramming  technique  which 
subdivides  information  processes  into  activities  and  data 
flow  (actigrams  and  datagrams),  SADT  consists  of  the 
following  functional  analysis  phases: 

1.  Diagramming  of  the  activity  and  data  aspects  of  the 
system. 

2.  Cross-referencing  of  activity  diagrams  and  data 
diagrams. 
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3. 


Additional  activity  and  data  diagramming  and  cross- 
referencing,  as  needed,  to  complete  the  functional 
analysis . 

4.  Analyzing  the  sequence  in  which  activities  can 
occur . 

5.  Identifying  mechanisms  which  will  implement  the 
functions,  and  which  will  act  as  a  bridge  to  the 
design  phase  [24:3-2]. 

Using  SADT  is  a  further  enhancement  of  data  flow  analysis 
techniques  in  that  it  mandates  strict  modern  software 
practices  including  top-down  design  and  step-wise  refinement 
when  addressing  each  requirement.  In  addition,  the  use  of  a 
technical  committee,  a  project  librarian,  and  a  chief 
analyst  insures  standardization  and  documentation  of  the 
system  requirements. 

Object  Oriented  Design.  The  strength  of  the  object 
oriented  design  technique  lies  in  it’s  ability  to  take  real 
world  objects  and  operations  and  map  them  into  a  problem 
space  capable  of  describing  problems  by  effecting  objects  on 
nouns  (4:44).  Steps  involved  include  the  following: 

1.  Define  the  Problem. 

a.  Determine  the  activity’s  purpose. 

b.  Determine  the  steps  performed. 

c.  Where  are  they  performed? 

d.  Who  performs  them? 

e.  How  long  does  it  take  and  how  often  is  it 
done? 

f.  Who  uses  the  resulting  information? 
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2.  Develop  an  informal  strategy. 

a.  Write  down  in  an  english  paragraph  a  way 
to  solve  the  problem. 

b.  Identify  objects  and  their  attributes. 

c.  Identify  operations  on  the  objects. 

d.  Establish  the  interface. 

3.  Formalize  the  strategy. 

a.  Implement  the  operations  (coding). 

b.  Iterate,  if  needed  (4:40-41). 

Requirements  analysis  techniques,  if  used  properly  can 

yield  cost  savings  by  ensuring  accurate  identification  of 
areas  prime  for  automation.  AFP  700-30  incorporates 
portions  of  the  above  techniques  in  helping  users  define 
their  requirements.  Once  requirements  are  defined,  the  task 
of  designing  and  implementing  systems  can  begin. 

Design  Considerations 

An  effective  management  information  system  is  one  that 
streamlines  day-to-day  office  tasks,  or  aids  in  speeding  up 
completion  of  those  tasks  (11:292).  One  problem  in  systems 
design  is  the  identification  of  those  tasks  which  can  and 
should  be  automated  and  those  which  should  remain  manual . 
However,  two  factors  are  likely  to  influence  the  selection 
of  candidate  tasks.  These  are  differences  between  systems 
designers’  views  of  the  environment,  and  end-users’ 
assessments  of  the  situation.  Kumar,  Kuldeep,  and  Welke 
dealt  with  the  first  factor  by  evaluating  the  perceived 
priorities  of  systems  designers.  These  researchers  hoped  to 
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substantiate  or  refute  the  assumption  that  systems 
developers  pay  more  attention  to  technical  and  economic 
values  during  design  and  less  attention  to 
socio-political-psychological  values  (13:8).  Using  a 
theoretical  model  of  the  relationship  of  values  to  behavior, 
the  authors  determined  empirically  that  systems  designers  do 
in  fact  pay  more  attention  to  the  first  two  values  (13:9). 
The  authors  felt  that  the  reason  for  the  displaced 
importance  of  technical  and  economic  values  over 
sociopolitical-psychological  values  was  due  to  the  reward 
structure  imposed  by  upper  management  (13:10).  In 
particular,  since  cost,  schedule  and  performance  were 
measurable  criteria  in  the  eyes  of  management,  and  end-user 
satisfaction  was  not,  the  design  process  was  geared  toward 
the  technical  and  economic  areas  that  could  be  quantified 
(13:10).  Because  design  considerations  may  not  adequately 
deal  with  all  the  areas,  systems  may  fail  upon 
implementation.  The  main  point,  however,  is  that  Air  Force 
systems  requirements  analysts  must  be  aware  of  the  users ’s 
values  when  determining  how  to  design  a  system  that  will 
satisfy  the  need.  Such  ignorance  of  users’  values  may 
result  in  their  non  acceptance  and  subsequent  system 
failure. 

Systems  analysts  may  or  may  not  be  aware  of  modern 
software  practices  (MSPs)  as  identified  by  Zmud .  These 
practices,  designed  to  place  some  structure  and 
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standardization  into  the  systems  design  phase  of 
development,  include  the  following: 

1 .  Top  down  development 

2.  Structured  design 

3.  Structured  reviews 

4.  Chief  programmer  teams 

5.  Configuration  management 

6.  Unit  development  folders  [27:1427]. 

Zmud  points  out,  however,  that  many  computer  specialists 
choose  not  to  use  these  techniques  because  they  either  view 
them  as  a  threat  to  their  autonomy  or  they  simply  do  not 
desire  to  learn  new  techniques.  Such  methods,  if  used  more 
widely,  could  enhance  not  only  the  design  of  systems,  but 
also  the  traceability  of  requirements.  In  addition  to  the 
use  of  the  MSPs  by  companies  which  market  software  products 
(27:1425),  the  military  attempts  to  model  these  methods. 

Such  practices  are  mandated  in  Department  of  Defense 
Directives  2167  (Software  Development  Standards  for  Mission 
Critical  Computer  Resources)  and  7935  (Development  Standards 
for  Non-Embedded  Computer  Resources). 

While  designers'  values  may  have  an  impact  on  successful 
implementation  of  a  system,  identification  of  tasks  which 
can  and  should  be  automated  is  also  an  important 
consideration  in  requirements  analysis.  If  a  system 
automates  an  unnecessary  task  while  failing  to  streamline  a 
"bottleneck"  in  the  office  information  flow,  resources  are 
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still  wasted.  A  study,  involving  the  use  of  a  model  to 
cognitively  identify  unstructured  tasks  in  an  office 
environment  as  candidates  for  automation  was  conducted  by 
Harris  and  Brightman  (11:292).  Through  the  use  of  the 
Critical  Task  Method,  they  attempted  to  understand  the 
bottlenecks  in  the  organization  and  identify  areas  which 
could  be  automated.  Relying  on  the  assumption  that 
end-users  can  correctly  identify  the  critical  tasks  which 
slow  the  production  in  an  office  (11:296),  the  authors  used 
a  5-step  approach  to  develop  requirements: 

1.  Interview  a  subsample  of  the  Knowledge  workers. 

2.  Develop  a  profile  of  task  descriptors. 

3.  Develop  a  profile  of  the  support  modes. 

4.  Validate  the  profile  of  task  descriptors  and 
support  modes. 

5.  Survey  the  hold-out  sample  [11:294-295]. 

Using  this  method  to  determine  requirements  for  an 

unstructured  office  environment,  they  were  able  to  identify 
the  critical  tasks  and  thus  steer  system  designers  toward 
those  areas. 

Montazemi  and  Conrath  (17:45),  through  the  use  of  a 
method  called  "cognitive  mapping",  also  attempted  to 
structure  information  systems  requirements  analysis  by 
identifying  eight  steps  and  integrating  them  into  the 
cognitive  mapping  process.  Cognitive  mapping  is  a  "mental 
method  of  representing  relationships  which  are  perceived  to 
exist"  and  empirically  examining  the  relationships  to 
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determine  the  reality  of  the  relationship  (17:46-47).  The 
authors  integrated  the  following  eight  steps  into  the 
cognitive  mapping  process  to  determine  bottlenecks  in  the 
information  flow: 

1.  Identification  of  the  user  set  and  interfacing 
organization , 

2.  Identification  of  decision  areas, 

3.  Definition  of  decision  areas, 

4.  Development  of  a  descriptive  model  of  the  system, 

5.  Development  of  a  normative  model  of  the  system, 

6.  Development  of  a  consensus  model  of  the  system, 

7.  Decision  model  identification  and  specification, 
and 

8.  Specification  of  information  requirements 
[17:45-46] . 

Using  the  above  method,  the  authors  asserted  that  their 
process  enabled  users,  who  were  working  in  a  very 
unstructured  office  environment,  to  determine  which  tasks 
were  most  critical  for  completion  of  their  daily  projects. 
They  were  also  able  to  determine  the  bottlenecks  in  the 
tasks,  and  were  thus  able  to  highlight  candidate  areas  for 
automation.  While  the  authors  identified  three  limitations 
to  this  model  (the  way  data  is  analyzed,  the  inability  to 
account  for  certain  inconsistencies,  and  an  incomplete 
integration  into  general  information  systems  requirements 
analysis),  the  cognitive  mapping  did  improve  understanding 
of  computer  decision  environments  by  the  application  of  data 
collection  and  analysis  techniques  (17:52-53). 
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Thus  far,  the  designers'  value  set  and  the  identification 
of  critical  tasks  have  been  at  issue.  A  third  design 
consideration  deals  with  the  ability  of  designers  to 
understand  the  cognitive  abilities  and  limitations  of  users. 
Benbaset  and  Taylor  (3:439)  asserted  that  management 
information  systems  could  be  improved  by  understanding  the 
way  humans  make  decisions.  Looking  at  two  factors  termed 
human  deficiencies  and  human  limitations,  they  suggested 
designing  computerized  decision  aids  which  model  the  human 
decision  making  process. 

They  defined  four  aspects  of  human  decision  making: 

1.  Ability  of  humans  to  combine  cues  from  multiple 
sources  in  making  judgments  -  People  generally 
prefer  simple  decision  making  strategies. 

2.  Ability  to  judge  probabilistic  events  -  An 
information  system  can  facilitate  the  way  decision 
makers  deal  with  uncertainty  by  providing  the  means 
to  judge  the  likelihood  of  probabilistic  events  more 
accurately. 

3.  Models  of  cognitive  complexity  -  Decision  aids 
should  not  be  so  complex  that  users  do  not 
understand  it’s  decision  making  process. 

4  Individual  differences  -  Decision  aids  should  be 
designed  to  facilitate  various  cognitive  styles 
[3:446] . 

A  final  design  consideration  should  be  the  matter  in 
which  systems  accommodate  users’  desires.  Ackoff  (1:B— 147) 
highlights  five  factors  which  designers  should  be  aware  of 
when  developing  information  systems: 

1.  Rather  than  providing  as  much  information  as 

possible  to  users,  systems  should  be  designed  to 
condense  and  filter  relevant  information. 
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2.  Users  do  not  always  need  the  information  they  want. 
An  explanatory  model  of  the  decision/task  process 
will  identify  relevant  information  requirements. 

3.  While  providing  managers  with  the  right  information 
may  result  in  better  decision  making,  it  is  also 
necessary  to  determine  how  well  managers  can  use  the 
needed  information. 

4.  More  communications  may  not  always  mean  better 
performance.  Organizational  structure  and 
performance  measurement  must  also  be  considered 
before  allowing  all  managers  free  access  to  all 
information . 

5.  In  addition  to  understanding  how  to  use  an 
information  system,  managers  should  also  be  trained 
to  evaluate  and  control  the  system,  and  have 
confidence  in  the  system  if  it  is  to  be  of  any  use 

[ 1 : B-147 1 . 

User  Involvement  and  End-user  Computing 

As  mentioned  earlier,  user  involvement  is  defined  as 
participation  in  the  system  development  by  representatives 
of  the  target  user  group.  An  integral  part  of  the  systems 
implementation  process,  users  should  assist  in  planning  and 
defining  information  requirements,  in  ensuring  that  the 
requirements  are  understood,  and  in  determining  if  the 
information  needs  which  have  been  defined  are  necessary 
(16:26).  Studies  have  overwhelmingly  pointed  out  that  such 
involvement  in  the  management  information  system  (MIS) 
design  process  is  essential,  but  where  that  involvement 
should  be  focused  is  questionable.  Ives  and  Olson  performed 
a  critical  analysis  of  studies  which  examined  the  impact  of 
user  involvement  and  determined  that  while  research  showed 
such  participation  was  a  determining  factor  for  system 
success  or  failure,  the  studies  did  not  pinpoint  the 
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particular  areas  where  user  involvement  was  most  effective 
(12:587).  While  more  research  should  be  performed  in  this 
area,  the  main  point  at  the  present  time  is  that  user 
involvement  in  the  wrong  areas  may  degrade  rather  than 
enhance  system  development. 

In  an  effort  to  focus  user  involvement  in  the  right 
areas,  Nutt  performed  analysis  to  determine  if  managers,  as 
users,  could  accurately  specify  their  MIS  requirements 
(18:139).  Nutt  suggested  two  steps  critical  in  the  MIS 
design  process:  "Identifying  key  activities  and  specifying 
the  information  required  to  support  these  activities" 
(18:139).  In  a  survey  of  practicing  managers  (in  lieu  of 
business  students),  his  study  suggested  a  more  accurate 
picture  of  MIS  design  concerns.  Results  also  questioned  the 
usefulness  of  cognitive  style  analysis,  citing  evidence  that 
those  factors  did  not  appear  to  affect  managers'  information 
preferences  (18:139).  More  importantly,  the  study  showed 
that  managers  as  users  could,  in  fact,  identify  their  MIS 
requirements  in  the  right  areas. 

Although  the  main  focus  of  user  involvement  is  adequate 
requirements  definition,  such  participation  also  aids  in 
system  acceptance  and  overall  system  success.  Baroudi, 

Olson  and  Ives  gathered  empirical  evidence  to  determine 
whether  user  involvement  during  information  systems 
development  would  enhance  both  the  system  usage  and  system 
satisfaction  (2:232).  They  conducted  an  extensive  review  of 
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similar  studies  and  concluded  that  while  those  studies 
related  user  involvement  to  system  quality,  system  usage, 
user  attitudes,  and  user  satisfaction,  they  failed  to  deal 
with  three  critical  areas.  These  included  a  precise 
operational  definition  of  user  involvement,  a 
psychometrically  accurate  measurement  of  user  involvement, 
and  an  ability  to  generalize  evidence  over  a  broad  spectrum 
of  information  systems  implementations  (2:232-233).  In  an 
effort  to  assess  these  issues,  the  authors  examined  two 
theoretical  models  of  user  involvement  and  tested  the 
relationships  of  those  models  to  system  usage  and  user 
satisfaction . 

Model  I  hypothesizes  that  user  involvement  will  lead  to 
both  system  usage  and  user  information  satisfaction  but 
as  system  usage  increases  it  leads  to  increased  user 
information  satisfaction.  This  model  is  based  on  the 
belief  that  system  use  leads  users  to  be  more  familiar 
with  the  system  and  to  discover  new  uses  for  it  which 
will,  in  turn  lead  to  enhanced  user  satisfaction  with  the 
system  [2:233]. 


The  authors  provided  the  following  definition  for  Model 
II: 

Model  2  proposes  that  user  involvement  will  also  lead  to 
both  system  usage  and  user  information  satisfaction  but 
that  the  more  satisfied  the  user  is  with  the  system  the 
more  he  or  she  will  be  inclined  use  it.  This  model 
assumes  that  as  use  demonstrates  that  a  system  meets 
user’s  needs,  satisfaction  with  the  system  should 
increase,  which  should  further  lead  to  greater  use  of  the 
system.  Conversely,  if  system  use  does  not  meet  the 
user’s  needs  satisfaction  will  not  increase  and  further 
use  will  be  avoided  [2:233]. 
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The  results  of  the  authors'  research  suggested  that  Model 
II  was  indeed  accurate  while  Model  I  was  not  (2:236).  While 
this  study  established  empirical  evidence  supporting  a 
correlation  between  user  involvement  in  system  development 
and  user  satisfaction  as  a  result  of  system  use,  the  authors 
recognized  several  limitations  of  their  approach.  Of 
interest  in  this  review  was  the  fact  that  the  user 
involvement  focus  was  on  the  middle  manager  (2:237). 

Further  studies  may  need  to  be  conducted  at  other  levels  of 
management  to  completely  substantiate  the  conclusions. 
However,  as  the  authors  suggest,  their  study  did 
substantiate  the  validity  of  user  involvement  in  successful 
information  systems  implementation. 

While  users  performed  mainly  clarification  and  acceptance 
roles  in  most  past  information  systems  implementations,  new 
development  tools  and  the  previously  mentioned  modern 
software  practices  may  allow  them  to  take  on  more 
responsibility  in  the  software  development  cycle.  Such 
roles  include  not  only  specifying  their  needs,  but  also 
designing  systems  and  software  to  satisfy  needs.  There  are 
several  benefits  to  this  method  of  development.  Leitheiser 
and  Wetherbe  explored  the  risks  and  opportunities  of  such 
end-user  computing.  End-user  computing  is  defined  as  the 
"use  and/or  development  of  information  systems  by  the 
principal  users  of  the  system’s  outputs  or  by  their  staffs" 
(15:338).  Opportunities  included  less  reliance  on  limited 
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information  systems  development  personnel,  more  direct 
system  implementation,  and  more  ownership  and  acceptance  by 
the  users  (15:338).  Apparent  risks  included  less 
standardization  in  design  techniques,  inadequate 
requirements  specification  due  to  lack  of  sufficient 
knowledge,  less  commitment  to  quality  assurance, 
changing/unstable  systems,  encouragement  of  private 
information  systems,  and  a  possible  accumulation  of 
unnecessary  information  due  to  poor  requirements  analysis 
(15:339).  Their  study  also  noted  eight  reasons  end-users 
choose  to  do  their  own  computing: 

1.  Lead  time  on  development  requests  are  shorter. 

2.  End-users  have  more  control  over  system  development 
and  use. 

3.  Services  are  not  available  from  the  MIS  department. 

4.  MIS  department  procedures  are  not  appropriate  for 
small  applications. 

5.  The  MIS  department  is  not  perceived  as  being 
concerned  about  user  needs. 

6.  End-users  want  to  learn  about  computing. 

7.  End-users  gain  more  flexibility. 

8.  The  information  systems  developed  better  meet  users’ 
needs  [ 15 : 338 ] . 

End-User  computing  is  significant  to  this  study  since 
defining  PC  systems  requirements  may  involve  user 
identification  and  selection  of  system  configuration  and 
operation.  With  that  in  mind,  certain  trends  involving  PC 
end-user  computing  in  the  business  world  were  noted  by  Lee. 


23 


In  his  study  of  12  organizations,  he  observed  that  users 
were  very  satisfied  with  their  PC’s,  and  sought  other  users 
as  key  sources  for  help  or  for  determining  system 
configurations  (14:321).  In  addition,  he  studied  the 
implementation  of  PC  based  systems  in  two  product  divisions 
to  see  if  user  planning  resulted  in  better  use  of  the 
systems.  The  results  indicated  that  while  both  divisions 
were  satisfied,  the  division  which  involved  users  in  a 
planning  process  was  much  more  productive  (14:322). 

Summary  of  Literature 

The  study  thus  far  has  examined  current  factors  which  may 
be  critical  in  t^e  requirements  analysis  of  office 
management  information  systems.  Three  areas;  requirements 
analysis  techniques,  systems  design,  and  user  involvement 
were  researched  to  determine  if  they  should  be  included  in 
determining  requirements.  From  a  review  of  the  research 
conducted,  it  was  evident  that  these  areas  must  be  key 
ingredients  in  requirements  analysis  if  the  system 
implementation  is  to  be  successful.  Available  literature 
suggests  the  following  approaches  critical  in  designing  and 
implementating  PC  based  management  information  systems  in 
Air  Force  organizations: 

1.  A  structured  requirements  technique  should  be  used. 

2.  Users  or  end-users  are  capable  of  defining  their 
requirements  and  designing  systems,  but  may  need 
some  guidance  from  MIS  professionals  to  limit  the 
risks  of  end-user  computing. 

3.  Designers  and/or  end-users  must  be  made  aware  of 
cognitive  limitations  inherent  in  humans  before 
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designing  systems  to  prevent  excessively  complicated 
or  useless  systems. 

4.  While  tools  and  techniques  are  available  for 

identification  of  information  requirements,  no 
method  is  available  for  users  to  determine  whether 
to  satisfy  those  requirements  using  database 
management  systems,  spreadsheets,  graphics,  word 
processors,  or  a  combination  of  those  systems. 


Such  findings  add  to  the  framework  for  determining  a 
working  model  to  assist  users  in  assessing  PC  software 
requirements.  The  next  chapter  expains  the  approach  used  to 
gather  information  from  actual  users  of  PC  based  management 
information  systems. 
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III.  METHODOLOGY 


Introduction 

This  chapter  presents  the  approach  employed  to  answer  the 
research  objectives  described  in  Chapter  I.  The  population 
of  interest,  the  type  of  data  collected,  the  location  of 
data  sources,  and  the  analytical  methods  are  discussed.  By 
using  the  approach  presented,  the  researcher  developed  three 
models  of  PC  software  requirements  analysis: 

1.  The  Normative  Model,  or  an  explanation  of  the 
directed  approach  to  determining  PC  software 
requirements  and  acquiring  the  software,  as 
prescribed  by  Air  Force  regulations  and 
policies . 

2.  The  Descriptive  Model,  or  an  explanation  of  the 
way  using  organizatons  actually  determined  the 
need  for,  and  acquired  the  PC  software. 

3.  The  Proposed  Model,  or  the  suggested  approach 
to  determining  PC  software  requirements  and 
subsequently  purchasing  software. 

The  methods  and  procedures  for  developing  the  models  are 
presented  in  this  chapter. 

General  Method 

Thirty  personnel  assigned  to  four  Air  Force  organizations 
at  Wright-Patterson  Air  Force  Base,  Ohio,  were  interviewed 
to  determine  how  software  requirements  were  identified,  how 
software  products  were  acquired  and  how  the  development  of  a 
PC  software  requirements  analysis  model  might  simplify  such 
actions.  One  individual  from  the  Aeronautical  Systems 
Division  (Air  Force  Systems  Command)  Information  Systems 


26 


Technology  Center  was  interviewed  to  determine  the  normative 
approach  for  acquiring  PC  software.  The  remaining  29 
individuals  were  members  of  three  organizations  and  were 
used  to  develop  a  descriptive  approach.  These  organizations 
included  the  Air  Force  Institute  of  Technology  (AFIT),  the 
B-1B  Systems  Program  Office  (B-1B  SPO )  ,  and  the  2750  Air 
Base  Wing/Logistics  Squadron,  Supply  Branch  (2750  DMS ) . 
Figure  1  displays  the  number  of  respondents  interviewed  by 
organization. 

These  organizations  were  selected  for  the  following 
reasons.  First,  the  missions  of  these  organizations 
represented  a  cross  section  of  Air  Force  organizational 
responsibilities.  Since  different  mission  requirements  may 
result  in  different  PC  software  requirements,  a  variety  of 
missions  was  necessary.  The  AFIT  mission  consisted  of 
academic  graduate  and  professional  continuing  education,  as 
well  as  consultant  work,  staff  assistance  and  research  in 
areas  of  systems  management,  engineering,  and  logistics. 
AFIT’s  mission  also  reflected  requirements  that  training 
institutions  throughout  the  Air  Force  may  encounter. 

The  B-1B  SPO  is  responsible  for  research,  development, 
acquisition,  and  deployment  of  an  aircraft  relatively  new  to 
the  Air  Force  weapons  inventory.  As  such,  it’s  mission  is 
comparable  to  many  of  the  Air  Force’s  other  research  and 
development  programs.  The  2750  DMS  supports  supply 
requirements  for  all  of  Wright-Patterson  Air  Force  Base,  and 
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contains  many  of  the  responsibilities  that  most  operational 
units  at  wing,  group  and  squadron  level  may  encounter. 

A  second  reason  for  choosing  these  organizations  was 
their  similarity  in  the  number  of  personnel  assigned.  All 
three  organizations  were  authorized  and  assigned  between  350 
and  400  personnel.  This  factor  was  useful  in  determining 
the  variety  and  quantity  of  software  types  that  various 
departments  and  sections  would  deem  necessary. 

The  third  reason  for  choosing  the  selected  organizations 
was  the  computer  hardware  configurations  involved.  All 
three  organizations  were  heavily  involved  in  automating  many 
tasks  through  the  use  of  both  PCs  and  mini  computers.  In 
addition,  they  all  contained  networking  capabilities  between 
their  mini  computers  and  their  PCs.  Such  configurations 
called  for  extensive  requirements  analysis  and  strict 
management  and  control  procedures  by  communications  and 
computer  (SC)  personnel. 

Types  of  Personnel  Interviewed 

The  individual  interviewed  from  the  ASD  ISTC  was  the 
manager  responsible  for  PC  support  within  ASD.  The  29 
personnel  interviewed  from  the  three  user  organizations 
consisted  of  8  individuals  classified  strictly  as  managers, 
15  users,  and  6  individuals  which  fell  into  both  categories 
( see  Figure  2  ) . 

Two  primary  types  of  individuals  were  selected  for 
interviews  at  each  organization.  Managers,  or  those 
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Figure  2 .  Classification  of  Respondents 
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responsible  for  authorizing  the  purchase  of  PC  software  were 
questioned,  since  they  could  best  indicate  how  they  acquired 
software  products.  Key  PC  users  were  also  interviewed, 
since  they  could  provide  a  good  measure  of  how  effective  a 
given  product  is  at  streamlining  tasks.  Managers  were 
considered  to  be  those  individuals  who  were  in  charge  of 
their  office  or  department  and  had  authority  to  validate 
requirements  initiated  by  their  subordinates.  Users 
consisted  of  key  individuals  who  rely  on  the  use  of  PCs  for 
the  accomplishment  of  their  duties.  Individuals  who  had 
some  decision  making  authority  for  software  acquisition  and 
who  also  used  PCs  for  daily  tasks  were  also  identified  and 
listed  in  a  separate  category  (designated  "Both").  By  grade 
structure,  13  of  the  individuals  interviewed  were  officers, 

4  individuals  were  enlisted,  and  the  remaining  13  (including 
the  ASD  ISTC  individual)  were  civilian.  Finally, 
individuals  were  also  classified  by  their  general  job 
titles.  Figures  3  and  4  provide  graphical  breakouts  of 
these  numbers. 

Procedures 

To  insure  accuracy  and  standardization  during  data 
collection,  personal  interviews  were  conducted  by  the 
researcher  at  each  organization.  This  method  of  data 
collection  was  selected  for  several  reasons.  First,  by 
using  personal  interview  techniques,  the  researcher  was  able 
to  explore  areas  where  specific  questions  were  possibly 
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Figure  3. Grade  Structure  of  Respondents 
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difficult  to  construct  in  advance  (26:289).  Since 
information  systems  requirements  analysis  is  still  a 
relatively  new  area  of  research,  answers  may  not  have  been 
as  readily  defined  as  they  would  be  in  other  disciplines. 
Thus  the  use  of  probing  and  funneling  techniques  during 
personal  interviews  served  to  address  areas  not  readily 
apparent  to  the  researcher  (26:289).  In  addition  to  the 
above  mentioned  reasons,  personal  interviews  were  also  used 
to  allow  a  greater  response  rate  from  the  candidate 
organizations  (6). 

While  some  questions  required  yes/no  answers,  the  primary 
type  of  questions  asked  during  the  personal  interviews  were 
semi-structured.  This  method  was  selected  so  that 
respondents  would  not  limit  their  answers  to  a  narrow  frame 
of  reference.  Also,  it  was  felt  that  such  structure  would 
minimize  the  possibility  of  leading  respondents  to  a 
preferred  answer  (6). 

To  minimize  the  possibility  of  observer  bias,  the 
researcher  employed  nonverbal  interviewing  techniques,  and 
also  structured  questions  in  such  a  way  as  to  not  elicit 
biased  responses.  Interview  questions,  during  preparation, 
were  validated  by  the  Thesis  Faculty  Advisor  and  two  other 
graduate  professors  to  ensure  their  effectiveness,  including 
one  in  the  Department  of  Communications  and  Organizational 
Behavior,  and  one  in  the  Department  of  Logistics  Management. 
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Specific  Method 


The  research  effort  was  conducted  in  five  phases. 

Each  phase  was  designed  to  answer  a  portion  of  the  research 
objectives : 

1.  The  following  four  types  of  literature  were  reviewed: 

a.  Literature  outlining  the  feedback  process 
between  users  and  developers  of  Management 
Information  Systems  helped  to  validate  the  role 
of  managers  and  users  in  determining  PC 
software  requirements. 

b.  Literature  describing  personal  interview 
techniques,  their  validity,  and  the  correct 
process  insured  an  unbiased  approach  to 
conducting  the  actual  survey. 

c.  A  review  of  Air  Force  Regulations  and 
publications  describing  the  current  procedure 
for  acquiring  PC  software  helped  the  author  to 
examine  the  effectiveness  of  the  current 
methods . 

d.  An  examination  of  other  requirements  analysis 
models  for  Management  Information  Systems 
contributed  to  the  development  of  a  proposed 
model  for  Air  Force  use  in  PC  software 
selection. 

2.  The  survey  questionnaire,  designed  to  provide 
answers  to  the  investigative  questions,  was  prepared 
in  a  format  understandable  by.  users.  Questions  were 
written  in  a  non  threatening  manner  and  laid  out  in 
a  logical  sequence  (See  Appendix  1  for  a  copy  of  the 
survey  instrument). 

3.  Interviews  were  scheduled  through  telephone 
conversations  with  the  respondents.  During  the 
telephone  conversations,  two  dates  were  established. 
The  first  session,  a  five  minute  interface, 
consisted  of  a  familiarization  of  the  topic  with  the 
respondents  and  the  presentation  of  the  survey 
instrument  to  them.  They  were  cautioned  not  to  fill 
out  any  portion  in  advance,  with  the  exception  of 
the  list  of  software  products  possessed.  The  second 
session  ranged  from  30  to  60  minutes  in  length,  and 
consisted  of  the  actual  data  collection  interview. 

At  the  conclusion  of  the  interview,  respondents  were 
asked  if  they  had  any  additional  comments.  These 
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comments  were  noted  and  used  as  additional  input  in 
the  development  of  a  requirements  analysis  model. 

The  first  interview  was  conducted  on  March  18,  1988, 
and  the  final  interview  was  conducted  on  June  4, 
1988. 

4.  Concurrent  with  the  development  of  the  survey 
questionnaire,  a  data  base  was  also  designed  for  the 
purpose  of  sorting  responses  by  various  categories 
related  to  the  investigative  questions.  As  each 
interview  was  completed,  the  information  was 
transferred  to  the  database  (see  Appendix  13  for  a 
description  of  the  Q&A  Data  Base  Management  System 
and  it’s  use  in  this  project). 

5.  Once  all  interviews  were  completed  and  all  data  was 

entered  into  the  data  base,  reports  were  developed 
and  generated  to  facilitate  answers  to  the 
investigative  questions  and  provide  the  descriptive 
information  mentioned  above.  The  following  reports 
were  compiled: 

a.  .  Types  of  Guidance  Obtained 

b.  Types  of  Software  Used 

c.  Critical  Software  Products 

d.  Users  of  the  Software 

e.  How  Products  Were  Acquired 

f.  How  Software  Needs  were  Determined 

g.  Software  Task  Analysis 

h.  User  Satisfaction 

i.  Product  Comparison 

j.  Perceived  Weekly  Usage 

k.  User  Comments 

Summary 

The  methodology  described  in  this  chapter  was  developed 
for  the  purpose  of  determining  the  adequacy  of  current  PC 
software  requirements  analysis  methods,  and  to  develop  a 
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better  method  if  the  current  practices  proved  insufficient. 
The  steps  used  to  conduct  the  study  were  necessary  to  insure 
a  reliable  and  valid  approach.  Using  the  data  collected 
along  with  the  literature  reviewed,  the  normative, 
descriptive,  and  proposed  requirements  analysis  models  were 
developed,  and  will  be  presented  in  the  next  chapter. 
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IV.  ANALYSIS  AND  DISCUSSION 


Overview 

The  purpose  of  this  chapter  is  to  present  the  results  of 
the  interviews  and  use  these  results  to  develop  a 
descriptive  model  of  PC  software  requirements  analysis.  The 
normative  model  was  also  developed  from  the  review  of 
literature  and  compared  against  the  descriptive  model.  From 
these  two  models,  a  proposed  model  is  presented. 

Findings 

Guidance  Received.  Respondents  were  asked  what  type  of 
guidance,  if  any,  they  sought  before  acquiring  software  for 
PCs.  Two  types  of  guidance;  consultant  or  staff  assistance, 
and  published  guides  or  journals  were  of  interest.  Figures  5 
and  6  provide  a  breakdown  of  the  sources  users  referenced. 

Although  regulations  suggested  that  users  obtain 
assistance  from  the  local  SCTC  or  communications  unit,  the 
most  sought  after  sources  for  assistance  were  other  users, 
followed  by  SCTC  guidance  and  third,  vendor  consultants,  for 
software  selection.  Under  written  or  published  assistance, 
almost  half  the  users  turned  to  either  popular  magazines  or 
no  guidance  at  all,  despite  the  availability  of  regulations 
and  SCTC  policy  letters.  Thus,  the  two  major  sources  of 
guidance  for  software  selection  appeared  to  be  other  users 
and  popular  journals. 
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Figure  5.  Sources  of  Staff  Guidance 
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Types  of  Software/Cost.  Although  respondents  were  asked 
to  provide  a  list  of  software  used  by  their  office^,  tms 
task  proved  to  be  difficult  to  fulfill  for  a  number  of 
reasons.  First,  most  offices  did  not  keep  an  in\ entory  of 
software  authorized  on  their  systems  (such  practices  had 
just  begun  to  be  implemented  at  the  time  of  the  interviews). 
Besides  a  lack  of  documentation,  several  versions  of  the 
same  commercial  software  products  were  available  within  the 
organizations  and  were  residing  simultaneously  on  some 
machines.  Second,  some  respondents  admitted  to  bringing  in 
privately  owned  software  to  accomplish  mission  tasks  on  the 
government  PCs.  Because  of  these  factors,  the  software 
inventories  conducted  for  this  study  could  not  be  validated 
as  accurate.  However,  software  products  which  were  used  or 
residing  in  each  office  were  noted.  Cost  figures  for  the 
products  were  obtained  either  from  the  individuals  or  from 
the  Standard  Small  Computer  Contract.  Appendix  2  lists  the 
software  products  residing  on  PC  systems  by  organization  and 
office.  Eleven  different  types  of  communications  packages, 
12  data  base  management  systems,  6  graphics  packages,  12 
programming  languages,  5  project  management  systems,  8 
spreadsheet  systems,  and  10  word  processors  were  among  the 
various  types  of  software  products  owned  or  used  by  the 
organizations  and  offices.  Prices  for  the  products  ranged 
from  no  cost  for  public  domain  packages  to  $5000.00  for  some 
data  base  management  systems. 


41 


Critical  Software  Products.  Since  a  myriad  of  software 


products  were  residing  on  the  PC  systems,  respondents  were 
asked  to  list  their  three  most  critical  products  in  order  of 
importance.  Critical  products  were  defined  to  be  the  top 
three  software  products  depended  upon  most  often  by 
respondents  and  other  individuals  in  their  offices. 

Appendix  3  provides  a  breakdown  of  critical  products  by 
software  type  category,  software  products,  individual 
ranking  (1,  2,  or  3),  and  by  offices  within  each 
organization.  Figure  7  displays  the  software  categories 
designated  critical  or  in  the  top  three.  Clearly,  graphics 
packages  were  depended  upon  the  most  for  office  tasks, 
followed  by  spreadsheets  and  data  base  management  systems. 
Word  processors  were  a  surprising  third,  followed  by 
integrated  packages,  which  consisted  of  software  which 
provided  a  combination  of  graphics,  spreadsheet,  data  base 
management,  word  processing,  and  communications  capabilities 
within  one  product.  These  findings  differ  slightly  from  a 
study  by  Lee  of  business  organizations  using  PC  software 
(14:316).  In  his  study  he  identified  spreadsheets  as  the 
most  critical  software  type,  followed  by  word  processors, 
programming  languages,  data  base  management  systems,  and 
graphics.  These  differences  may  be  attributed  to  a  number 
of  factors.  First  the  sample  size  of  the  present  study  was 
much  smaller  than  Lee's.  Second,  over  the  past  two  years, 
more  sophisticated  yet  more  user  friendly  packages  have  been 
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developed,  making  them  more  attractive  to  users.  This  has 
been  the  case  in  the  five  software  types  selected  by 
respondents  in  this  -study. 

Users  of  the  Software.  Respondents  were  asked  to  state 
the  primary  users  of  their  critical  software  packages. 
Appendix  4  lists  by  category  the  software  types,  the 
specific  products,  and  primary  users.  Data  gathered  for 
this  question  was  unclear,  however,  since  most  respondents 
provided  vague  answers.  As  such,  many  of  the  responses 
included  "everyone"  as  primary  users.  ’The  researcher  was 
able  to  distinguish  some  categories  of  users  by  looking  at 
the  missions  of  the  various  offices  and  determining  the  job 
classifications.  Based  on  these  factors,  Figure  8  provides 
a  breakout  of  primary  users  for  the  most  critical  software 
types  and  products. 
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Figure  8.  Primary  Users  of  Software 
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Technical/clerical  personnel,  managers,  cost  analysts  and 


instructors  all  were  indicated  as  primary  users  of 
communications  packages,  data  base  managers,  graphics 
packages,  spread  sheets,  word  processors,  and  integrated 
packages.  Computer  analysts  and  engineers  had  different 
primary  packages,  but  this  was  expected  based  on  the 
narrower  scope  of  their  duties  and  the  small  number 
surveyed . 

How  Software  Products  were  Acquired.  Five  main  sources 
mentioned  for  acquiring  critical  software  included  the 
Standard  Small  Computer  Contract,  sole  source  or  special 
purchase  actions,  the  use  of  a  contract  negotiated  by  ASD 
SCTC  with  software  distributors,  vendor  provided  copies  of 
software  (for  evaluation  and  comments),  and  self  purchase. 
Figure  9  provides  a  chart  showing  the  most  used  sources. 
Appendix  5  provides  further  details  of  this  information  by 
software  type,  product  name,  and  unit. 

Although  Air  Force  regulations  dictate  the  use  of  the 
Standard  Small  Computer  Contract  for  the  majority  of 
software  acquisitions,  in  practice  only  slightly  more  than  a 
quarter  of  the  users  acquired  critical  software  through 
those  means.  The  ASD  contract  was  a  modification  of  the  sole 
source  method.  Combining  the  sole  source  and  the  ASD 
software  methods  together  resulted  in  36. 7%  of  all  critical 
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How  Software  Needs  were  Determined.  Respondents  were 
asked  to  state  how  they  determined  the  need  for  the  critical 
software  packages  they  were  using.  The  intent -of  this 
question  was  to  determine  if  any  requirements  analysis 
techniques  were  used  prior  to  purchasing  the  software.  No 
users  employed  the  formal  techniques  described  in  Chapter 
II.  However,  users  did  find  requirements  for  software  based 
on  the  need  to  accomplish  six  knowledge  work  tasks,  and  four 
qualitative  factors.  The  knowledge  work  tasks  included 
authoring  and  presentation,  planning  and  decision  support, 
monitoring  and  control,  organizing  and  scheduling,  diagnosis 
and  problem  finding,  and  communication.  The  qualitative 
factors  included  interoperability  and  transportability  of 
data  between  PCs,  mainframes  and  other  software  types  and 
products,  evaluation  through  demonstrations  or  periodicals, 
cost  considerations,  and  other  factors  such  as  downwardly 
mandated  software  product  purchases.  Figures  10a  and  10b 
display  the  number  of  products  (by  software  categories, 
knowledge  work  categories,  and  qualitative  categories)  that 
underwent  a  needs  analysis.  Appendix  6  provides  a  more 
detailed  breakout  of  the  information. 

The  data  indicates  that  users  saw  a  strong  need  for 
authoring  and  presentation  tasks  as  well  as  interoperability 
and  transportability  of  the  information.  However,  in  almost 
every  case,  users  did  not  perform  an  evaluation  before 
acquiring  the  software.  Rather,  they  acquired  the  software 
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Figure  iOb.  How  SW  Needs  Were  Determine 
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first  and  determined  the  need  as  they  became  comfortable 
with  the  software  products. 

Software  Task  Analysis.  Respondents  were  asked  to  detail 
the  tasks  they  intended  to  simplify  with  the  software,  and 
correspondingly,  provide  a  breakdown  of  the  tasks  which  were 
in  fact  streamlined  and  which  ones  were  not.  Figures  11a 
through  13  provide  a  breakout,  in  numbers,  of  the  results. 

In  addition,  Appendix  7  shows  a  more  detailed  description  of 
the  same  information.  Clearly,  the  majority  of  knowledge 
work  tasks  addressed  included  authoring  and  presentation, 
monitoring  and  control,  and  diagnosis  and  problem  finding. 
Software  types  used  to  satisfy  these  requirements  included 
data  base  management  systems,  graphics  packages, 
spreadsheets,  word  processors,  and  integrated  packages.  In 
addition,  the  need  to  accomplish  interoperability  and 
transportability  of  the  information  was  also  identified  and 
satisfied . 

User  Satisfaction.  Since  most  of  the  tasks  intended  for 
streamlining  were  accomplished  by  the  critical  software 
products,  one  would  expect  the  users  to  be  satisfied  with 
the  products.  Such  was  the  case,  with  very  few  exceptions 
(see  Appendix  8).  The  few  areas  where  users  had  not  been 
able  to  satisfy  requirements  included  communications, 
interoperability  and  transportability  of  information,  and 
authoring  and  scheduling.  In  these  instances,  users  felt 
disatisfied  with  the  software’s  performance.  The 
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products  in  each  of  those  categories  which  did  not  meet  the 
users’  needs  included  MS-Kermit,  Procomm,  and  ZStem 
(communications),  Ability  and  Enable  (interoperability  and 
transportability),  and  Wordstar  (authoring  and 
presentation ) . 

Product  Comparison.  Respondents  were  asked  if  they 
considered  using  other  software  types  or  products  to 
accomplish  the  intended  tasks.  In  most  cases,  they  did  not 
perform  any  type  of  detailed  comparison  (see  Appendix  9).  Of 
the  few  comparisons  which  were  performed,  almost  all  users 
looked  only  in  the  same  software  type  category,  comparing 
spreadsheets  against  other  spreadsheets,  for  example.  Only 
one  user  determined  that  a  different  software  type  would 
better  satisfy  the  requirements.  That  user  chose  to  take 
tasks  which  were  presently  being  accomplished  using  a 
spreadsheet  for  personnel  management  (monitoring  and 
control)  and  transfer  the  information  into  a  data  base 
management  system. 

Frequency  and  Duration  of  Software  Use.  Respondents  were 
asked  what  daily  (D),  quarterly  (Q),  and  annual  or  non 
recurring  tasks  (Y)  were  performed  using  the  critical 
software  products  (see  figure  14).  They  were  also  asked  to 
estimate  the  number  of  hours  each  product  was  used  on  a 
weekly  basis.  Appendices  10  and  11  list  the  responses.  In 
addition,  daily,  quarterly  and  annual  tasks  were  categorized 
into  the  knowledge  work  fields  by  software  type. 
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Communications,  data  base  management  systems,  graphics, 
integrated  systems,  spreadsheets  and  word  processors  were 
used  continuously,  mainly  for  authoring  and  presentation, 
monitoring  and  control,  and  diagnosis  and  problem  solving. 

User  Comments.  Respondents  were  asked  if  they  would  like 
to  provide  any  additional  comments  to  provide  input  into  the 
study.  Twenty  individuals  provided  comments,  which  are 
listed  in  Appendix  12.  Six  areas  drew  repeated  remarks,  and 
are  mentioned  below. 

Software  Purchases.  Users  felt  that  purchasing 
software  at  the  same  time  as  the  hardware  procurement  was 
much  easier  than  purchasing  software  at  a  later  date. 
Specifically,  justifying  software  alone  was  considered  a 
very  tedious  task  which  required  extensive  amounts  of  user 
research  and  great  risk  of  disapproval  by  SC  requirements 
committees.  Consequently,  users  would  buy  as  much  software 
up  front  as  possible,  then  determine  needs  for  the  software 
at  later  dates.  This  resulted  in  vast  amounts  of  unused 
software  residing  in  PCs  or  in  office  shelves. 

SC  Staff  Support.  The  aforementioned  "buy  now, 
justify  later"  attitude  of  many  users  was  a  result  of  a 
feeling  that  the  SC  staff  did  not  provide  enough  support  for 
users  of  PC  based  systems.  Some  users  wanted  the  SC  staff 
to  play  a  greater  role  in  helping  users  determine  their 
requirements.  Conversely,  some  users  wanted  more  autonomy 
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in  selecting  specific  software  products.  Specifically, 
oncestaff  assistance  enabled  users  to  determine  what  type  of 
software  application  should  be  used  to  accomplish  the 
defined  knowledge  work  requirement,  users  wanted  the 
authority  to  select  their  own  software  product.  At  the 
present,  many  felt  they  were  restricted  to  using  only 
software  listed  on  the  Standard  Contract. 

c.  Training  was  insufficient  for  most  of  the 
software  available  on  the  Standard  Contract.  Users  felt 
they  could  get  more  productivity  out  of  the  software  if  they 
were  able  to  obtain  or  provide  training  for  more  of  the 
personnel  in  their  offices.  While  classroom  training  was 
available  for  many  of  the  packages,  the  waiting  list  was 
long,  and  the  duration  of  the  training  was  considered  too 
brief  to  provide  immediate  productivity. 

d.  Users  wanted  to  see  more  software  which  could  be 
compatible  with  other  applications  and  products.  In  some 
instances,  users  were  mandated  into  using  certain  packages, 
but  saw  a  need  to  obtain  other  products  so  they  could  be 
compatible  with  their  customers.  The  SC  solution  to  the 
problem  of  software  incompatibility  was  to  attempt  product 
standardization.  Users  suggested,'  however,  that 
interoperability  and  transportability  of  data  between 
applications  and  between  products  would  result  in  greater 
productivity  and  still  maintain  user  autonomy. 
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Hardware  Availability.  Software  use,  in  some 


instances,  was  limited  by  the  availability  of  hardware 
systems.  While  users  had  a  definite  need  for  automation  of 
knowledge  work,  an  insufficient  number  of  systems  were 
provided  for  use.  As  such,  the  software  may  have  been 
under-utilized,  not  because  of  a  misstated  need,  but  because 
of  poor  configuration  of  systems. 

Standard  Contract.  Software  on  the  Standard 
Contract  was  not  keeping  pace  with  the  commercially 
available  products.  In  some  instances,  newer,  more 
powerful,  more  user  friendly,  and  less  expensive 
applications  were  discovered  by  users,  but  not  allowed  for 
purchase.  In  addition,  there  were  no  provisions  on  the 
Standard  Contract  for  purchasing  upgrades  to  previously 
acquired  products. 

Discussion 

From  the  information  gathered,  a  definition  of  the 
normative  or  prescibed  method,  and  the  descriptive  or  actual 
method  of  acquiring  PC  software  can  be  developed.  While 
both  systems  have  merits  and  problems,  they  proved  to  be 
useful  in  developing  a  proposed,  model  as  well. 

The  Normative  Model.  The  driving  factors  behind 
acquiring  PC  hardware  or  software  were  the  identification  of 
ways  to  increase  the  probability  of  mission  success  or  ways 
to  decrease  the  cost  of  mission  support  (9:1).  Based  on 
these  criteria,  the  prescribed  methods  of  determining  both 


60 


software  and  hardware  requirements  are  identical: 

a.  Conduct  an  Information  systems  Requirements 
Analysis . 

b.  Identify  requirements  which  cannot  be  satisfied 
by  existing  methods. 

c.  Record  the  unsatisfied  mission  requirements. 

d.  Record  current  costs  of  not  satisfying  those 
mission  requirements. 

e.  Consult  the  SC  staff  for  a  technical  solution. 

f.  Prepare  an  SC  Requirements  Document  (9:33). 

g.  Obtain  SC  Requirements  Board  approval  for 
purchase  of  the  PC  system  and  software. 

1.  Table  of  Allowances  (T/A)  007  and  009  are 
the  primary  sources  for  requirements  for 
standard  small  computers. 

2.  The  MAJCOM  SCTC  recommends  acceptable 
software  for  the  stated/approved 
requirements . 

3.  If  the  SCTC  cannot  provide  the  required 
software  the  user  may  obtain  the  software 
through  the  Standard  Contract.  If  the 
software  is  not  available  on  the  Standard 
Contract,  the  user  may  identify 
commercially  available  software,  and 
develop  a  sole  source  justification  to 
purchase  that  software  [8:4]. 

From  the  viewpoint  of  most  users,  the  problem  with  the 
normative  model  was  the  inability  of  the  SCTC  or  the  SC 
staff  to  define  an  appropriate  technical  software  solution 
for  stated  mission  requirements.  Users  were  dismayed  with 
choices  of  software  available  on  the  contract,  and  were  not 
provided  enough  guidance  on  which  products  to  acquire. 
Although  they  were  restricted  primarily  to  the  software 
available  on  the  Standard  Contract,  information  gathered 
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indicates  they  were  able  to  order  as  many  types  of  software 
as  they,  not  the  SC  staff,  deemed  necessary.  The  normative 
model  was  lacking  in  its  ability  to  assist  users  in 
specifying  the  appropriate  software  for  their  stated 
knowledge  work  tasks. 

The  Descriptive  Model.  The  way  organizations  decribed 
their  acquistion  process  differs  greatly  from  the  prescribed 
approach.  Users,  as  a  rule,  did  not  identify  requirements 
before  acquiring  software.  The  method  was  generally  as 
follows : 

a.  Identify  software  products  and  their 
applications  through  three  main  sources: 

1.  Other  users. 

2.  Popular  magazines 

3.  Commercial  vendors,  demonstrations,  and 
evaluations. 

b.  Determine  organizational  requirements  which  may 
be  streamlined  by  the  use  of  the  software. 

c.  Justify  the  requirement  for  the  product,  mainly 
through  sole  source  means  versus  Standard 
Contract  sources. 

d.  Acquire  the  product  upon  SC  Requirements  Board 
approval . 

e.  Discover  further  office  applications  through 
the  continued  use  of  the  product. 

The  benefit  of  this  method  lies  in  the  ability  of  users 
to  discover  new  methods  of  simplifying  tasks  without  relying 
on  SC  personnel,  which  users  have  felt  were  unresponsive 
(Appendix  12:  User  Comments).  The  main  problem  rested  with 
improper  solutions  to  office  tasks  through  the  purchase  of 
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an  inappropriate  software  product.  No  barriers  existed  to 
prevent  users  from  trying  to  apply  spreadsheet  solutions, 
for  example,  to  data  base  management  specific  tasks. 

The  Proposed  Model .  The  proposed  model  takes  issues 
identifed  throughout  this  study  into  consideration,  and 
incorporates  a  method  by  which  users  may  be  able  to  define, 
justify,  and  satisfy  their  software  requirements  with  the 
right  software  tool.  The  key  to  the  model  is  the  development 
of  a  table  showing  the  knowledge  work  tasks  most  used  by  the 
respondents  (Table  1).  Software  types  are  recommended  based 
on  the  knowledge  work  identified.  The  steps  are  as  follows: 

a.  Identify  the  mission. 

b.  Model  the  flow  of  information  through  the 
organization  using  techniques  such  as  the 
following : 

1.  AFP  700-30. 

2.  Data  Flow  Analysis. 

3 .  SADT . 

c.  Identify  critical  tasks  or  outputs  which  must 
be  satisfied  to  meet  mission  requirements. 

d.  Identify  inputs  to  those  critical  outputs. 

e.  Identify  areas  where  bottlenecks  occur  in  the 
information  flow. 

f.  Identify  bottlenecks  which  cannot  be 
streamlined  through  existing  methods. 

g.  Of  those  bottlenecks  which  cannot  be 
streamlined  through  existing  methods,  identify 
the  ones  which  can  and  should  be  automted  to 
streamline  the  flow  of  information. 
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Table  1.  PC  Software  Requirements  Analysis  Model 
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Table  1  (Continued).  PC  Software  Requirements  Analysis  Model 


AUTH  PLAN  MON IT  ORG  DIAG 
PRES  D.S.  CTRL  SCH  P.S. 


COMM 


INVENTORY 

MANAGEMENT 


FILE 

MANAGEMENT 


STATUS  REPORTS  DB 

WP 


SUSPENSE 

TRACKING 


BUDGET  STATUS 
REPORTS 


PREPARING 
CHARTS  FOR 
PRESENTATIONS 
AND  REPORTS 


BUDGETING 


PREPARING 

PERSONNEL 

ROSTERS 


TREND  ANALYSIS 


SENSITIVITY 

ANALYSIS 


PC-TO-PC 

CONNECTIVITY 


PC-TO-HOST 

COMPUTER 

CONNECTIVITY 


65 


h.  Categorize  the  bottlenecks  into  knowledge  work 
tasks.  i.  Using  Table  1,  determine 

the  type  of  software  which 
would  best  satisfy  the 
knowledge  work. 

j.  Evaluate  the  following  qualitative  factors 
before  purchasing  the  software: 

1.  Cost. 

2.  Compatibility  with  hardware  and  other 
software  products  in  the  same 
software  category. 

3.  Interoperability  and  transportability 
of  information  between  different 
applications  (Can  the  product  import 
and  export  files  to  and  from  the 
popular  data  base  management  systems, 
Word  processors,  communications 
packages,  spreadsheets,  and  graphics 
packages? ) . 

4.  Legality  of  use  (if  the  product  is 
public  domain  or  shareware). 

5.  Ease  of  use. 

6.  Necessity  for  or  availability  of 
training  in  the  use  of  the  software. 

k.  Purchase  the  software  and  perform 

evaluations  on  the  actual  use  as  well  as 

unintended  uses. 

Steps  "a"  through  "g"  are  a  combination  of  practices 
currently  recommended  by  the  Air  Force  and  the  available 
literature  (Chapter  II).  The  remaining  steps  are  factors 
which  may  result  in  a  better  determination  of  the 
appropriate  software  type  and  product.  This  is  based  on  the 
information  gathered  through  the  interviews  conducted. 
Summary 

This  chapter  has  presented  the  findings  and  analysis 
based  on  interviews  conducted  among  thirty  individuals 
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spanning  four  organizai tons .  From  these  interviews, 
significant  trends  in  PC  software  selection  were  identified 
and  reported.  Using  these  trends  along  with  the  literature 
reviewed  in  Chapter  II,  three  models  were  designed  for  the 
purpose  of  PC  software  requirements  analysis.  The  normative 
model  described  the  methods  prescribed  by  regulations  and 
publications.  The  descriptive  model  provided  the  actual 
methods  users  employed  in  determining  PC  software 
requirements.  Finally  the  proposed  model  suggests  a  more 
effective  and  efficient  means  of  determining  software 
requirements  and  evaluating  software  uses.  This  model  is 
based  on  identifying  knowledge  work  first  and  then  mapping 
the  appropriate  software  solution  to  the  knowldedge  work. 

The  findings  and  models  developed  in  this  chapter  form  the 
foundation  for  the  following  Chapter  V,  Conclusions  and 
Recommendations. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


Overview 

The  purpose  of  this  chapter  is  to  present  conclusions  and 
recommendations  derived  from  the  analyses  presented  in 
Chapter  IV.  The  information  detailed  in  both  Chapter  II  and 
Chapter  IV  was  used  to  develope  three  PC  software 
requirements  analysis  models,  which  were  presented  in  the 
last  chapter.  This  chapter  will  provide  answers  to  research 
questions  as  well  as  the  research  objectives.  In  addition, 
the  limitations  of  this  study  are  addressed.  Finally, 
recommendations  for  future  research  in  the  area  of  PC 
requirements  analysis  are  presented. 

Results 

The  objective  of  this  study  was  to  determine  how  Air 
Force  organizations  selected  PC  software,  to  examine  the 
effectiveness  of  the  standard  practices,  and  to  determine  if 
a  better  method  could  be  developed.  Through  an  analysis  of 
the  information  gathered,  the  following  conclusions  are 
suggested : 

Answers  to  Research  Questions 

As  a  result  of  this  analysis,  the  following  research 
questions  can  now  be  answered: 

1.  What  guidance  do  organizations  receive  when 


purchasing  PC  software?  Users  obtained  guidance  primarily 
from  other  users  and  from  popular  magazines  when  determining 


which  software  to  obtain.  Although  government  regulations 
were  available,  they  were  seldom  referenced.  Additionally, 
although  the  regulations  directed  users  to  the  SC  staff,  the 
users  have  found  such  sources  to  be  non-responsive  to  their 
requests . 

2.  What  software  products  are  organizations 
currently  using?  Organizations  were  primarily  using 
graphics  packages,  spreadsheets,  data  base  managers,  word 
processors,  and  integrated  packages  to  accomplish  their 
tasks.  The  majority  of  tasks  accomplished  by  these  software 
packages  included  authoring  and  scheduling,  monitoring  and 
control,  and  diagnosis  and  problem  finding.  In  addition, 
organizations  were  using  software  to  convert  information 
from  different  applications  into  forms  compatible  with  the 
software  they  were  familiar  with. 

3.  How  do  organizations  determine  which 
software  products  to  obtain?  As  a  general  rule,  no  real 
requirements  analysis  was  being  conducted.  The  most  common 
method  was  to  purchase  as  much  software  as  perceived 
necessary  for  future  tasks  at  the  same  time  as  the  hardware 
purchase  (according  to  users,  this  was  easier  to  justify  to 
SC  requirements  committees)  and  then  determine  the  need  for 
the  software  later. 

4.  Are  the  software  products  being  used  for 
their  intended  purpose?  There  was  no  noticeable  difference 
between  the  tasks  intended  for  streamlining  by  the  software 
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and  the  tasks  actually  streamlined.  Thus,  users  were  using 
the  products  for  what  they  intended  to  use  them  for. 

However,  in  a  few  cases,  the  intended  use  of  the  product  may  . 
have  been  inadequate,  as  in  the  cases  where  users  attempted 
to  accomplish  organizing  and  scheduling  tasks  with  a 
spreadsheet  instead  of  a  data  base  management  system. 

5.  Could  a  different  software  product  have 
been  used  to  accomplish  the  same  task  at  less  cost?  In  mai.y 
cases,  users  were  employing  outdated  or  original  versions  of 
software  products  to  accomplish  tasks.  Newer  versions,  had 
they  been  available  for  government  purchase,  would  have 
simplified  tasks  immensely  (for  example,  some  users  were 
using  DBASE  II,  when  DBASE  III+  is  a  much  more  versatile 
product).  Users  were  hindered  by  the  lack  of  ability  to 
obtain  software  updates  directly  from  commercial  vendors. 

In  addition,  some  applications  could  have  been  performed 
with  a  different  software  type  (i.e.,  a  spreadsheet  versus  a 
data  base  manager).  Two  factors  prevented  the  most 
efficient  use  of  the  software.  First,  users  did  not  have 
the  tools  to  evaluate  the  uses  of  different  software  types 
available  for  the  knowledge  work  tasks.  Second, 
evaluations  were  limited  to  demonstrations  of  single 
products  in  most  cases,  with  little  comparisons  among  like 
applications  products. 

6.  Which  daily,  mid-range  and  long-range 


operations  are  benefiting  from  the  use  of  the  software? 


Authoring  and  presentation,  monitoring  and  control, 
organizing  and  scheduling,  and  diagnosis  and  problem  finding 
were  streamlined  through  the  use  of  software  products. 

These  products,  including  communications,  data  base 
management,  graphics,  spreadsheet,  word  processing,  and 
integrated  packages,  were  used  to  accommodate  the  knowledge 
work  tasks.  In  addition,  they  served  to  provide 
transportability  and  interoperability  of  the  information. 

7.  How  often  are  individual  software  products 
used?  The  types  of  products  mentioned  in  question  6  above 
were  used  continuously  for  the  accomplishment  of  their 
intended  tasks.  Most  products  were  used  in  excess  of  10 
hours  per  week  per  product,  with  hardware  availability  being 
the  only  hindrance  to  more  extensive  use. 

8.  Who  (by  organizational  position)  uses  the 
software?  There  was  no  clear  pattern  of  use  by  position. 

In  most  cases,  the  critical  products  were  used  by  all 
personnel  assigned  to  the  office  interviewed. 

Answers  to  Research  Ob.iectives 

In  order  to  develop  an  effective  PC  software 
requirements  analysis  model,  the  following  observations  were 
necessary : 

1.  Determining  whether  or  not  a  set  of  uniform  PC 
software  selection  criteria  at  base  level  existed. 

2.  Determining  how  effective  the  existing  methods  of 
selecting  PC  software  were. 

3.  Determining  what  additional  factors  that 
organizations  should  evaluate  before  acquiring  PC 
software . 
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The  following  conclusions  were  made: 

Objectives  1  and  2.  Two  standards  for 
acquiring  PC  software  exist.  The  normative  approach 
prescribed  by  Air  Force  regulations  outlines  a  process  for 
determining  requirements  and  acquisition  of  software. 
However,  this  approach  is  not  clear  in  helping -users  select 
the  appropriate  software.  The  descriptive  approach  has 
differed  from  the  regulatory  approach  in  that  users  select 
software  first  and  then  find  a  need  to  fit  the  software. 

Data  suggests,  however,  that  at  times  this  has  resulted  in 
less  optimum  use  of  the  software. 

Objective  3.  A  requirements  analysis  model  was 
necessary  to  specifically  provide  users  with  a  means  of 
categorizing  their  requirements  into  knowlede  work  tasks, 
and  to  select  software  designed  to  satisfy  the  identified 
knowledge  work.  Such  a  model  has  been  developed  using  the 
tasks  identified  by  respondents  and  the  literature  available 
on  the  subjects  of  MIS  design,  user  involvement,  and 
requirements  analysis  techniques.  This  model,  presented  in 
Chapter  IV,  is  offered  as  a  solution  to  the  current  problem. 
Scope  ..nd  Limitations 

The  following  limitations  applied  to  this  research: 

Types  of  Systems  Analyzed.  Only  IBM  PC  compatible 
systems  were  analyzed.  This  was  done  to  take  advantage  of 
regulations  guiding  the  Standard  Small  Computer  Contract 
specifications,  which  currently  directs  organizations  to 
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purchase  such  systems  for  general  purpose  office  automation. 
In  addition,  future  PC  procurements  will  be  conducted 
through  the  Standard  Small  Computer  Contract.  Consequently, 
data  gathered  in  this  study  may  aid  future  users  in  their 
requirements  analysis. 

Types  of  Software.  Only  Applications  software 
requirements  were  addressed.  Systems  software  requirements 
were  excluded,  since  all  computers  on  the  Standard  Small 
Computer  Contract  were  delivered  with  a  Disk  Operating 
System  ( DOS ) . 

Interviews .  Interview  input  was  limited  to  two 
areas:  SCTC  personnel,  and  organizations  currently  using 
PCs. 

Sample  Size.  The  sample  size  of  the  population 
interviewed  was  small.  While  accurate  for  the  organizations 
under  study,  a  greater  number  of  organizations  with  varying 
sizes  and  structures  need  to  be  surveyed  to  substantiate  the 
effectiveness  of  the  proposed  model  over  the  entire  Air 
Force . 

Recommendations 

This  study  highlights  several  trends  in  PC  software 
selection  by  organizations.  The  proposed  requirements 
analysis  model  presented  in  Chapter  IV  is  recommended  as  a 
possible  solution  to  streamlining  the  selection  of  PC 
software.  Additionally,  the  questions  and  methods  discussed 
in  chapter  III  serve  as  a  means  for  determining  an  acurate 
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requirements  analysis  strategy  for  PC  based  management 
information  systems.  Specifically,  organizations  may  wish 
to  use  the  survey  in  Appendix  1  as  an  evaluation  tool  for 
existing  PC  software  use  within  current  offices. 

While  the  conclusions  reached  are  accurate  for  the 
organizations  surveyed  in  this  study,  the  limitations  of  the 
sample  size  and  number  of  units  interviewed  may  not  reflect 
the  most  used  knowledge  work  tasks  or  the  software  products 
used  to  satisfy  those  tasks  for  the  Air  Force  in  general. 
Future  researchers  may  wish  to  employ  the  use  of  the  survey 
in  Appendix  1  on  a  larger  population  sample.  Addtionally, 
since  most  software  requirements  appeared  to  be  driven  by 
the  hardware  acquisition  process,  one  may  wish  to  study  this 
area  in  detail.  Another  related  area  which  appears  fruitful 
for  further  study  is  the  way  training  is  obtained  for 
software.  Finally,  the  interface  between  SC  personnel  and 
PC  end-users  should  be  looked  at  in  greater  detail  to 
determine  a  more  effective  interface. 

Summary 

The  reseach  presented  here  is  based  on  the  interviews  of 
thirty  people  in  four  organizations.  Consequently,  the 
scope  may  be  limited.  However,  the  study  achieved  three 
important  goals.  First,  the  study  established  the  way  PC 
software  acquisition  should  be  procured,  according  to  Air 
Force  regulations.  Second,  the  study  examined  the 
effectiveness  of  the  prescribed  methods,  and  also  examined 
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the  reliability  of  standard  software  acquisition  practices. 
Finally,  the  study  presented  a  proposed  model  to  streamline 
the  PC  software  requirements  analysis  process.  This  model 
is  designed  to  help  organizations  decide  which  tasks  should 
be  automated  and  what  types  of  software  should  be  acquired 
to  accomplish  those  tasks. 

Air  Force  organizations  must  streamline  operations  and  do 
more  with  less,  if  they  are  to  continue  operations  despite 
the  current  budgetary  climate.  The  existence  of  information 
systems- allows  mission  objectives  to  be  achieved  in  spite  of 
manpower  reductions  and  increased  responsibilities.  The 
development  of  a  PC  software  requirements  analysis 
methodology  may  allow  more  organizations  to  obtain  the 
appropriate,  needed  software.  By  applying  the  model 
detailed  in  Chapter  IV,  better  selection  of  PC  software 
should  result  in  increased  mission  effectivenes  at  less  cost 
to  the  Air  Force. 
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Appendix  1 .  Personal  Computer  Software  Requirements 
Analysis  Survey 


AUTHOR : Capt  D.  Handy 
DATE/TIME  OF  INTERVIEW: 

BUILDING  # : _ 

ROOM  #: _ 

POINT  OF  CONTACT: _ 


PERSONAL  COMPUTER  SOFTWARE  REQUIREMENTS 
ANALYSIS  SURVEY 

The  purpose  of  this  interview  is  to  examine  how  Air  Force 
units  at  Wright  Patterson  Air  Force  Base  currently  determine 
their  PC  Software  requirements,  and  the  way  in  which  they 
acquire  their  software.  The  information  gathered  in  this 
interview  will  be  used  along  with  interviews  from  other  base 
organizations  to  develop  a  requirements  analysis  model  for 
easier  determination  of  software  that  organizations  may  need 
to  streamline  mission  operations. 


BACKGROUND /DEMOGRAPHIC  INFORMATION 

Name  of  unit _ 

Unit  mission _ 

Size  of  Unit _ 

a.  #  Officers  _ 

b.  #  Enlisted  _ 

c.  #  Civilians _ 

Person  interviewed /rank _ 

a.  Job  Title _ 

b.  Length  of  time  in  unit _ 

c.  Length  of  time  in  present  position _ 

INDIVIDUAL  RESPONSES  WILL  BE  KEPT  CONFIDENTIAL  AND  ALL 
RESPONSES  WILL  BE  REPORTED  BY  GROUP  MEANS  OR  TRENDS 
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1.  Please  identify  the  types  of  software  products  your 
unit  is  currently  using: 

TYPE  OF  PRODUCT _ NAME  OF  PRODUCT _ 

COST 

Word  Processors _ 

Spreadsheets  _ 

Data  Base  Management  Systems _ 

Scheduling  systems _ 

Graphics  _ 

Forms  publications _ 

Accounting  _ 

Communications 

Data  Security  _ 

Programming  Languages  _ 

Desk  Top  Management  _ 

Other  (specify) _ 
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2.  Which  three  software  packages  are  the  most  critical  to 


b. 


How  did  you  acquire  those  particular  software 
systems? 


Did  you  find  it  necessary  to  consult  other 
organizations  or  individuals  before  acquiring  your 
software  for  your  PC’s  (Samples  are  listed  below)? 

a.  MAJCOM/Base  Small  Computer  Technical  Center 

b.  Local  Communications  unit 

c.  Base  Administrative  Communications  office 

d.  Base  Contracting  Office 

e.  Civilian  consulting  firms  (please  specify) 

f.  Internal  resources  (please  specify) 

g.  Did  not  consult  anyone 

Did  you  find  it  necessary  to  consult  any  regulations 
or  publications  when  you  were  determining  your 
organization’s  requirements  (samples  are  listed 
below ) ? 

a.  AFR  700-3,  Information  Systems  Requirements 
Processing 

b.  AFR  700-26,  Acquisition  and  Management  of  Small 
Computers 

c.  AFR  700-30,  How  to  Determine  and  Justify 
Information  Systems  Requirements  in  an  Office 
Environment 

d.  Other  regulations/publications/policy  letters 

( specify ) _ 

e.  Professional/popular  journal  or  magazine 

( specify) _ 

f.  Did  not  consult  any  regulations  or  publications 


5.  (FOR  EACH  OF  THE  SOFTWARE  PRODUCTS  MAINTAINED)  How 
did  your  unit  determine  the  need  for  that  particular 
software  product? 

6.  (FOR  EACH  OF  THE  SOFTWARE  PRODUCTS  USED)  Which  tasks 
did  you  intend  to  streamline  with  the  software 
package? 

7.  (FOR  EACH  SOFTWARE  PRODUCT  USED)  Which  of  these 
particular  tasks  were  streamlined  through  the  use  of 
that  software  product? 

8.  (FOR  EACH  SOFTWARE  PRODUCT  USED)  Which  of  these 
particular  tasks  were  not  streamlined  through  the 
use  of  the  software  product? 

9.  (FOR  EACH  SOFTWARE  PRODUCT  USED)  In  your  opinion, 
did  the  software  product  successfully  satisfy  its 
intended  use? 

10.  (FOR  EACH  SOFTWARE  PRODUCT  USED)  What  other  software 
products  did  you  consider  for  accomplishing  the 
task? 

11.  (FOR  EACH  SOFTWARE  PRODUCT  USED)  Why  did  you  decide 
to  select  the  chosen  software  product  over  the  other 
choices? 

12.  Which  daily  tasks  have  been  simplified  through  the 
use  of  the  software  products? 

13.  Which  monthly  or  quarterly  tasks  have  been 
simplified  through  the  use  of  the  software  products? 

14.  Which  annual  or  nonrecurring  tasks  have  been 
simplified  through  the  use  of  the  software  products? 

15.  (FOR  EACH  SOFTWARE  PRODUCT  USED)  How  often  does  your 
unit  use  the  software  product? 
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Appendix  2:  Software  Inventory 


SW  PRODUCT 


TYPE  NAME 

UNIT 

OFFICE 

UNIT  COST 

CO  CALL 

AAAAA 

JJJ 

$0.00 

JJJJJ 

$0.00 

JJ 

$0.00 

CHI  BOARD 

BBBBB 

DMSC 

$0.00 

COORDINATOR 

CCCCC 

LLL 

$500.00 

MS-KERMIT 

CCCCC 

LL 

PC  TERM 

CCCCC 

LLZ 

PCXFER 

CCCCC 

LLL 

PROCOMM 

CCCCC 

LL 

LLLL 

AAAAA 

JJJJJ 

JJJ 

SMART  TERM 

CCCCC 

LLL 

$350.00 

240 

Z  COMM 

CCCCC 

LLL 

Z  STEM 

CCCCC 

LL 

$33.00 

LL 

$33.00 

LLL 

$33.00 
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sw 

TYPE 


PRODUCT 

NAME 


UNIT 


OFFICE  UNIT  COST 


DB 


LLZ 

$33 . 00 

LLL 

$33.00 

AAAAA 

JJJJJ 

$33.00 

JJJ 

$33.00 

JJJJJ 

$33.09 

ZSTEM 

BBBBB 

EEEEE 

$33.00 

CCCCC 

DDD 

$33.00 

AAAAA 

EE 

$33.00 

CONDOR 

BBBBB 

FFFF 

CCCCC 

FFF 

CONDOR  III 

CCCCC 

FF 

D  BASE  III+ 

BBBBB 

FFFF 

$362.00 

DATAEASE 

CCCCC 

DDD 

$0.00 

DBASE  II 

CCCCC 

FFZ 

$355.00 

AAAAA 

GGGGG 

$355.00 
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sw 

TYPE 


PRODUCT 


NAME 

UNIT 

OFFICE 

UNIT  COST 

EE 

$355.00 

DBASE 

BBBBB 

HHHME 

$355 . 00 

II ; DBASEI I I 

DBASE  III 

BBBBB 

HHHME 

$355.00 

HHHMS 

$  3  5  5 . 0C 

CCCCC 

FFG 

$355.00 

aaAaa 

III 

$355.00 

IIIII 

$355.00 

EE 

$355.00 

DBASE  III+ 

.  BBBBB 

HHHC 

$355.00 

FFFFPA 

$499.00 

CCCCC 

LLL 

$355.00 

FF 

$355.00 

FFF 

$355.00 

FFFA 

$355. 
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sw 

PRODUCT 

TYPE 

NAME 

UNIT 

OFFICE 

UNIT  COST 

HOMEBASE 

AAAAA 

III 

MICROX 

BBBBB 

HHHCDI 

$45000.00 

PARTS  MASTER 

BBBBB 

HHHCDI 

$5000 . 00 

HHHCX 

$5000.00 

FFFF 

$5000.00 

PCFILE 

AAAAA 

III 

Q&A 

CCCCC 

FFFA 

DM 

WINDOWS 

BBBBB 

HHHMS 

AAAAA 

GGGGG 

$0.00 

EE 

$0.00 

FP 

PAGEMAKER 

BBBBB 

FFFFPA 

$595.00 

GR 

CAD-3D 

AAAAA 

GGGGG 

CHART 

BBBBB 

HHHC 

$0.00 

HHHCR2 

$0.00 

HHHMS 

FFFF 

$0.00 
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sw 

TYPE 


PRODUCT 


NAME 

UNIT 

OFFICE 

UNIT  COST 

FFFFPA 

$0.00 

AAAAA 

GGGGG 

$0.00 

III 

$0.00 

IIIII 

$0.00 

EE 

$0.00 

GRAFT ALK 

BBBBB 

HHHC 

$0.00 

CCCCC 

FF 

$0.00 

HARVARD 

GRAPHICS 

CCCCC 

LL 

$362.00 

FF 

$362.00 

FFG 

$362.00 

FFF 

$362.00 

FFFA 

$362.00 

FFZ 

$362.00 
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sw 

TYPE 


PRODUCT 

NAME 


UNIT 


OFFICE  UNIT  COST 


IT 


AAAAA 

SHOWMAKER 

CCCCC 

STATGRAPHICS 

CCCCC 

ABILITY 

CCCCC 

ENABLE 

BBBBB 

CCCCC 

FFF 

$362.00 

DDD 

$362.00 

III 

$362.00 

EE 

$362.00 

FFZ 

FF 

FFFA 

$79.00 

HHHC 

$87.00 

HHHME 

$87.00 

FF 

$87.00 

FFG 

$87.00 

FFF 

FFFA 

$87.00 

FFZ 

$87.00 

FFF 

$87.00 

DDD 

$87.00 

86 


sw 

TYPE 


PL 


PRODUCT 


NAME 

UNIT 

OFFICE 

UNIT  COST 

AAAAA 

GGGGG 

$87.00 

III 

$87.00 

mu 

$87.00 

EE 

$87.00 

EXCELLERATOR 

CCCCC 

DDD 

MICROSTAT 

CCCCC 

DDD 

$0 . 00 

PATHMASTER 

CCCCC 

DDD 

$0.00 

QBS 

CCCCC 

DDD 

$0.00 

RESNET  LAN 

AAAAA 

EE 

$0.00 

PRINT  CONT 

SIMPLE-1 

CCCCC 

FF 

TOOLS 

BBBBB 

HHHMS 

ASSEMBLER 

CCCCC 

DDD 

BASIC 

BBBBB 

HHHME 

$12.00 

CCCCC 

FF 

$12.00 

FFG 

$12.00 

FFZ 

$12.00 

87 


sw 

TYPE 


PRODUCT 

NAME 


UNIT 


OFFICE  UNIT  COST 


DDD 

$12.00 

AAAAA 

GGGGG 

$12.00 

III 

$12.00 

IIIII 

$12.00 

c 

CCCCC 

DDD 

C-86 

CCCCC 

FF 

C86 

CCCCC 

DDD 

$0.00 

COBOL 

BBBBB 

HHHC 

$15.00 

AAAAA 

EE 

$15.00 

FORTRAN 

CCCCC 

FF 

$16.00 

FFZ 

$16.00 

DUD 

$16.00 

AAAAA 

GGGGG 

$16.00 

EE 

$16.00 

GW  BASIC 

BBBBB 

HHHC 

$12.00 

88 


sw 

TYPE 


PRODUCT 

NAME 


UNIT 


OFFICE  UNIT  COST 


PM 


AAAAA 

EE 

$12.00 

MS  FORTRAN 

BBBBB 

HHHC 

$16.00 

PASCAL 

BBBBB 

HHHC 

$12 . 00 

CCCCC 

FF 

$12.00 

FFZ 

$12.00 

DDD 

$12.00 

AAAAA 

GGGGG 

$12.00 

EE 

$12.00 

TURBO  PASCAL 

CCCCC 

LLL 

$40.00 

TURBOPASCAL 

CCCCC 

FFF 

$40.00 

FFZ 

$40.00 

FFF 

Z-BASIC 

CCCCC 

DDD 

$12.00 

CAPPS 

CCCCC 

DDD 

EXPERT 

SYSTEM 

CCCCC 

DDD 

89 


sw 

TYPE 


PRODUCT 

NAME 


UNIT 


OFFICE  UNIT  CObT 


HARVARD 

TOTAL 

PROJECT  MGR 

CCCCC 

DDD 

SUPERPROJECT 

EXPERT 

CCCCC 

DDD 

TIMELINE 

BBBBB 

HHH.C 

$53 . 00 

CCCCC 

FF 

FFFA 

DDD 

$53.00 

AAAAA 

III 

EE 

$33.00 

LOTUS  123 

BBBBB 

HHHCR2 

$362.00 

FFFF 

$362.00 

CCCCC 

LLL 

$362.00 

FF 

$362.00 

FFF 

$362.00 

FFFA 

$362.00 

FFZ 


$362.00 


sw 

TYPE 


PRODUCT 


NAME 

UNIT 

OFFICE 

UNIT  COST 

DDD 

$362.00 

AAAAA 

GGGGG 

$362.00 

III 

$362.00 

mu 

$362.00 

EE 

$362.00 

PEACHCALC 

AAAAA 

EE 

$87.00 

PERFECT  CALC 

ccccc 

FFF 

QUATRO 

CCCCC 

FF 

FFG 

$40.00 

FFF 

SUPERCALC  2 

BBBBB 

FFFFPA 

$350.00 

SUPERCALC  3 

BBBBB 

FFFF 

$350.00 

CCCCC 

FFFA 

SUPERCALC 

III 

CCCCC 

FF 

VP  PLANNER 

CCCCC 

FF 

91 


sw 

TYPE 


PRODUCT 

NAME 


UNIT 


OFFICE  UNIT  COST 


FFG 

$40.00 

FFF 

$20.00 

FFZ 

$20.00 

VP  PLUS 

CCCCC 

LLL 

$100.00 

BASS 

CCCCC 

LLL 

$40.00 

BASSBASE 

CCCCC 

FF 

BASS VIEW 

CCCCC 

FF 

MATHCAD 

CCCCC 

LLL 

$200.00 

FFZ 

MICROSTAT 

CCCCC 

FF 

$362.00 

FFZ 

DDD 

POWERPACK 

CCCCC 

LLL 

$20.00 

MS  WORD 

CCCCC 

LLL 

$400.00 

MULT I MATE 

CCCCC 

FF 

AAAAA 

III 

92 


sw 

TYPE 


PRODUCT 


NAME 

UNIT 

OFFICE 

UNIT  COST 

PCWRITE 

AAAAA 

III 

PEACHTEXT 

CCCCC 

FF 

$0.00 

DDD 

$0.00 

AAAAA 

GGGGG 

$0.00 

III 

$0.00 

EE 

$0.00 

VOLKS  WRITER 

CCCCC 

FFZ 

VOLKSWRITER- 

3 

CCCCC 

FF 

WORDPERFECT 

CCCCC 

DDD 

$0.00 

WORDSTAR 

BBBBB 

HHHC 

$130.00 

HHHCR2 

$130.00 

HHHME 

$130.00 

HHHMS 

$130.00 

CCCCC 

LL 

$130.00 

FF 

$130.00 

FFFA 

$130.00 

93 


sw 

TYPE 


PRODUCT 

NAME 


UNIT 


OFFICE  UNIT  COST 


WRITE  ONE 


WRITESOFT 


FFZ 

$130.00 

FFF 

$130.00 

DDD 

$130.00 

AAAAA 

GGGGG 

$130.00 

III 

$130.00 

CCCCC 

LLL 

$400.00 

FF 

BBBBB 

FFFFPA 
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Appendix  3:  Critical  Software  Products 
SW  CRIT  PRODUCT 


TYPE 

UNIT 

OFFICE 

PROD# 

NAME 

UNIT  COST 

CO 

CCCCC 

LL 

1 

MS-KERMIT 

PROCOMM 

Z  STEM 

$33.00 

LLL 

1 

SMART  TERM 

240 

$350.00 

2 

COORDINATOR 

$500.00 

DDD 

3 

ZSTEM 

$33.00 

AAAAA 

III 

3- 

Z  STEM 

$33 . 00 

DB 

BBBBB 

HHHCDI 

1 

MICROX 

$45000.00 

2 

PARTS  MASTER 

$5000.00 

HHHCX 

1 

PARTS  MASTER 

$5000.00 

HHHME 

1 

DBASE 

I I ; DBASEII I 

$355.00 

DBASE  III 

$355.00 

HHHMS 

2 

DBASE  III 

$355.00 

FFFF 

1 

CONDOR 

2 

D  BASE  III+ 

$362.00 

3 

PARTS  MASTER 

$5000.00 

FFFFPA 

2 

DBASE  III+ 

$499.00 

CCCCC 

FFG 

2 

DBASE  III 

$355.00 

FFF 

3 

DBASE  I 11+ 

$355.00 

FFF 

4 

CONDOR 

AAAAA 

mu 

3 

DBASE  III 

$355.00 

GR 

BBBBB 

HHHCR2 

3 

CHART 

$0.00 
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sw 

TYPE 

UNIT 

OFFICE 

CRIT 

PROD# 

PRODUCT 

NAME 

UNIT  COST 

GR 

BBBBB 

FFFF 

2 

CHART 

$0.00 

FFFFPA 

1 

CHART 

$0.00 

CCCCC 

LL 

3 

HARVARD 

GRAPHICS 

$362.00 

FF 

2 

HARVARD 

GRAPHICS 

$362.00 

FFF 

1 

HARVARD 

GRAPHICS 

$362.00 

FFFA 

3 

HARVARD 

GRAPHICS 

$362.00 

FFZ 

2 

HARVARD 

GRAPHICS 

$362.00 

3 

HARVARD 

GRAPHICS 

$362.00 

FFF 

3 

HARVARD 

GRAPHICS 

$362.00 

DDD 

1 

HARVARD 

GRAPHICS 

$362.00 

$362.00 

$362.00 

2 

HARVARD 

GRAPHICS 

$362.00 

AAAAA 

GGGGG 

1 

CHART 

$0.00 

EE 

CHART 

$0.00 

IT 

CCCCC 

FFFA 

1 

ABILITY 

$79.00 

FFF 

2 

ENABLE 

$87.00 

DDD 

2 

ENABLE 

$87.00 

$87.00 

3 

ENABLE 

$87.00 

AAAAA 

III 

1 

ENABLE 

$87.00 

96 


sw 

TYPE 

UNIT 

OFFICE 

CRIT 

PROD# 

PRODUCT 

NAME 

UNIT  COST 

IIIII 

2 

ENABLE 

$87.00 

EE 

1 

ENABLE 

$87.00 

$87.00 

OT 

CCCCC 

DDD 

2 

QBS 

$0.00 

PL 

AAAAA 

GGGGG 

3 

BASIC 

$12.00 

PM 

CCCCC 

DDD 

3 

EXPERT 

SYSTEM 

TIMELINE 

SS 

BBBBB 

HHHCR2 

1 

LOTUS  123 

$362.00 

FFFF 

1 

LOTUS  123 

$362.00 

3 

SUPERCALC  3 

$350.00 

CCCCC 

FF 

3 

LOTUS  123 

$362.00 

QUATRO 

SUPERCALC 

III 

VP  PLANNER 

FFG 

1 

VP  PLANNER 

$40.00 

FFF 

2 

LOTUS  123 

$362.00 

QUATRO 

VP  PLANNER 

$20.00 

FFZ 

1 

LOTUS  123 

$362.00 

VP  PLANNER 

$20.00 

2 

LOTUS  123 

$362.00 

FFF 

1 

PERFECT  CALC 

AAAAA 

GGGGG 

2 

LOTUS  123 

$362.00 

97 


sw 

TYPE 


UNIT 


CRIT 

OFFICE  PROD# 


PRODUCT 

NAME 


UNIT  COST 


ST  CCCCC 


WP  BBBBB 


CCCCC 


AAAAA 


III 

2 

LOTUS  123 

$362.00 

mu 

1 

LOTUS  123 

$362.00 

EE 

2 

LOTUS  123 

$362.00 

3 

LOTUS  123 

$362.00 

LLL 

3 

BASS 

$40.00 

MATHCAD 

$200.00 

POWERPACK 

$20.00 

FFZ 

1 

MICROSTAT 

3 

MICROSTAT 

HHHCR2 

2 

WORDSTAR 

$130.00 

HHHME 

2 

WORDSTAR 

$130.00 

HHHMS 

1 

WORDSTAR 

$130.00 

FFFFPA 

3 

WRITESOFT 

LL 

2 

WORDSTAR 

$130.00 

FF 

1 

MULTIMATE 

PEACHTEXT 

$0.00 

VOLKSWRITER- 

3 

WORDSTAR 

$130.00 

WRITE  ONE 

FFFA 

2 

WORDSTAR 

$1-30.00 

FFF 

1 

WORDSTAR 

$130.00 

DDD 

1 

WORDPERFECT 

$0.00 

EE 

1 

PEACHTEXT 

$0.00 
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sw 

TYPE 


CRIT  PRODUCT 

UNIT  OFFICE  PROD#  NAME  UNIT 


3  PEACHTEXT 


COST 


$0.00 
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Appendix  4:  Primary  Users  of  Software  Products 


sw 

TYPE 

PRODUCT 

NAME 

UNIT 

CRIT 

PROD# 

PRIMARY 

TYPE  OF 

USERS 

CO 

COORDINATOR 

ccccc 

2 

N/A 

MS-KERMIT 

ccccc 

1 

EVERYONE 

PROCOMM 

ccccc 

1 

EVERYONE 

SMART  TERM 

240 

ccccc 

1 

N/A 

Z  STEM 

ccccc 

1 

EVERYONE 

AAAAA 

3 

ALL  PERSONNEL 

ZSTEM 

CCCCC 

3 

FACULTY 

DB 

CONDOR 

BBBBB 

1 

GS-11,  CHIEF 

CCCCC 

4 

DR  XXXXX  -  FOR 
ARCHIVAL  ONLY 

D  BASE  III+ 

BBBBB 

2 

SSGT-NCOIC 

DBASE  II 

BBBBB 

1 

SUPPLY  CLERKS 

DBASE  III 

BBBBB 

1 

SUPPLY  CLERKS 

TSGT ; GS-7 

2 

REQUISITIONING 

TECHNICIANS 

CCCCC 

2 

1 ; LTCOL  XXXXXXXX 

AAAAA 

3 

1  CIVILIAN  GS-12 

DBASE  I 11+ 

BBBBB 

2 

GS-9  COST  ANALYST 

CCCCC 

3 

6  INSTRUCTORS  USE 
FOR  ADMIN  DUTIES 

MICROX 

BBBBB 

1 

GS-2 

PARTS  MASTER 

BBBBB 

1 

A1C/ASST  NCOIC 

2 

GS-2 
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sw 

TYPE 

PRODUCT 

NAME 

UNIT 

CRIT 

PROD# 

PRIMARY 

TYPE  OF 

USERS 

3 

SSGT,  NCOIC  TRNG 

GR 

CHART 

BBBBB 

1 

GS-11  COST 

ANALYST 

2 

MANAGER  AND 
TECHNICIANS 

AAAAA 

1 

EVERYONE  (8) 

2 

PROJECT 

MANAGERS 

HARVARD 

GRAPHICS 

CCCCC 

1 

30  PEOPLE  - 
INSTRUCTORS 
SPECIFIED  BY  VICE 
COMMANDANT 

TOTAL  DEPT 

ALL  PROFESSORS 
FACULTY ; STAFF 

2 

FACULTY 

SECRETARIES 

FACULTY 

FACULTY 

3 

FACULTY 

PROFESSORS 

12  FACULTY 
EVERYONE 

ALL  MEMBERS 

IT 

ABILITY 

CCCCC 

1 

4  FACULTY 

ENABLE 

CCCCC 

2 

FACULTY 

THESIS  REVIEWERS 
FACULTY 

3 

PRIVATELY  OWNED 
COPY 

AAAAA 

1 

CLERICAL ; MANAGER 
ALL  PERSONNEL 
FINANCIAL 

MANAGERS 
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PRIMARY 


sw 

PRODUCT 

CRIT 

TYPE  OF 

TYPE 

NAME 

UNIT 

PROD# 

USERS 

2 

EVERYONE 

OT 

QBS 

CCCCC 

2 

FACULTY  MEMBER 

PL 

BASIC 

AAAAA 

3 

2  ENGINEERS 

PM 

EXPERT 

SYSTEM 

CCCCC 

3 

FACULTY  MEMBER 

TIMELINE 

CCCCC 

3 

CAPT  XXXXXX 

SS 

LOTUS  123 

BBBBB 

1 

MANAGER  AND 
TECHNICIANS 

NCOIC,  REPAIR 

CYCLE  SUB-UNIT 

CCCCC 

1 

FACULTY 

2 

FACULTY 

PROFESSORS 

ASSOCIATE  DEAN 
INSTRUCTORS ; 

LTCOL  XXXXXXXXX 

DEPT  HEAD 

3 

FACULTY 

AAAAA 

1 

EVERYONE 

2 

3  ENGINEERS 

ALL  MANAGERS 

WORKERS  (COST 
ANALYSTS ) 
PROFESSIONALS 

3 

CLERICAL 

PERSONNEL 

QUATRO 

CCCCC 

2 

ASSOCIATE  DEAN 
INSTRUCTORS; 

LTCOL  XXXXXX 

DEPT  HEAD 

3 

FACULTY 

SUPERCALC  3 

BBBBB 

3 

MANAGER/TECHNICIANS 
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sw 

TYPE 

PRODUCT 

NAME 

UNIT 

CRIT 

PROD# 

PRIMARY 

TYPE  OF 
USERS 

SUPERCALC 

III 

CCCCC 

3 

FACULTY 

VP  PLANNER 

CCCCC 

1 

FACULTY 

1; DIRECTOR  OF 

STUDENT 

OPERATIONS 

2 

ASSOCIATE  DEAN 
INSTRUCTORS ; 
LTCOL  XXXXXXXXX 
DEPT  HEAD 

3 

FACULTY 

ST 

BASS 

CCCCC 

3 

N/A 

MATHCAD 

CCCCC 

3 

N/A 

MICROSTAT 

CCCCC 

1 

FACULTY 

PROFESSORS 

3 

FACULTY 

POWERPACK 

CCCCC 

3 

N/A 

WP 

MULT I MATE 

CCCCC 

1 

SECRETARIES; 

FACULTY 

PEACHTEXT 

CCCCC 

1 

SECRETARIES; 

FACULTY 

AAAAA 

1 

FINANCIAL 
MANAGERS ; 

3 

CLERICAL  WORKERS 

VOLKSWRITER- 

3 

CCCCC 

1 

SECRETARIES; 

FACULTY 

WORDPERFECT 

CCCCC 

1 

PRIVATELY  OWNED 
PRODUCT 

WORDSTAR 

BBBBB 

1 

PURCHASE  CLERKS; 
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sw 

TYPE 


PRODUCT 

NAME 

UNIT 

CRIT 

PROD# 

PRIMARY 
TYPE  OF 
USERS 

2 

TSGT ; GS- 7 

CCCCC 

1 

SECRETARIES ; 
FACULTY 

2  PEOPLE 

2 

EVERYONE 

1  FACULTY 

WRITE  ONE 

CCCCC 

1 

SECRETARIES; 

FACULTY 

WRITESOFT 

BBBBB 

3 

GS-9,  COST 
ANALYST 
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Appendix  5:  How  Critical  Software  Products  Were  Acquired 


sw 

TYPE 

PRODUCT 

NAME 

UNIT 

HOW 

ACQUIRED 

CO 

COORDINATOR 

CCCCC 

PURCHASE  THROUGH 
CCCCC 

MS-KERMIT 

CCCCC 

SEAT  OF  THE 

PANTS ; INTUITION 

PROCOMM 

CCCCC 

SEAT  OF  THE 

PANTS; INTUITION 

SMART  TERM 
240 

CCCCC 

SELF  PURCHASE 

Z  STEM 

CCCCC 

SEAT  OF  THE 

PANTS; INTUITION 

AAAAA 

CAME  WITH  SYSTEM 

ZSTEM 

CCCCC 

STANDARD  ZENITH 
CONTRACT 

DB 

CONDOR 

BBBBB 

STANDARD  ZENITH 
CONTRACT  (WITH 
PURCHASE  OF  Z100) 

D  BASE  III+ 

BBBBB 

PURCHASE 

DBASE 

I I ; DBASEI I I 

BBBBB 

STANDARD  ZENITH 
CONTRACT 

DBASE  III 

BBBBB 

STANDARD  ZENITH 
’  CONTRACT 

STANDARD  ZENITH 
.  CONTRACT 

STANDARD  ZENITH 
CONTRACT 

CCCCC 

ACQUIRED  AS 
EVALUATION  COPY  FROM 
COMPANY 

AAAAA 

ASD  CONTRACT 

DBASE  III+ 

BBBBB 

LOCAL  PURCHASE  { AF ) 

CCCCC 

SINGLE  COPY 
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sw 

TYPE 


PRODUCT 

NAME 


UNIT 


HOW 

ACQUIRED 


PURCHASED  FOR 
FACULTY  EVALUATION 


MICROX 

BBBBB 

PARTS  MASTER 

BBBBB 

ORDERED  BY  BASE 

GR  CHART 

BBBBB 

STANDARD  CONTRACT 
SUPPLY 

USAF  PUBLIC  DOMAIN 
SOFTWARE 

AAAAA 

STANDARD  ZENITH 
CONTRACT 

PUBLIC  DOMAIN 

HARVARD 

GRAPHICS 

CCCCC 

CAME  WITH  SYSTEM 
ACQUISITION; HIGHER 

DECISION  LEVEL 
FORM  9  PURCHASE 
CSRD 

PURCHASED  SOLE 
SOURCE 
DON’T  KNOW 
CCCCC/SC  CHANNELS 
ZENITH  CONTRACT 
CONSULTED  FF ; MR 
XXXXXXX  +  LTCOL 
XXXXXXX  +  XXXXXXXXXX 
GSA  CONTRACT 
PRIVATE  USE; PRODUCT 
DEMONSTRATION 
GOVT  PURCHASE 

IT  ABILITY  CCCCC  FORM  9  PURCHASE 

ENABLE  CCCCC  ZENITH  CONTRACT 

STANDARD  ZENITH 
CONTRACT 

CAME  WITH  SYSTEM 

ACQUISITION 

VENDOR  COURTESY  COPY 

AAAAA  STANDARD  ZENTIH 

CONTRACT 

CAME  WITH  SYSTEM 
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sw 

TYPE 

PRODUCT 

NAME 

UNIT 

HOW 

ACQUIRED 

ASD  CONTRACT 

ASD  CONTRACT 

OT 

QBS 

CCCCC 

PUBLIC  DOMAIN  ( LTCOL 
XXXXXXX ) 

PL 

BASIC 

AAAAA 

GOVT  PURCHASE 

PM 

EXPERT 

SYSTEM 

CCCCC 

INFORMAL 

CONTACTS; PROFESS. 
RELAT. ; VENDOR 

DEMOS ; EVAL 

COPY ; STUDENTS 

TIMELINE 

CCCCC 

ZENITH  CONTRACT 

SS 

LOTUS  123 

BBBBB 

PURCHASED  THROUGH 
BASE 

STANDARD  CONTRACT 

CCCCC 

MAINFRAME  BURROUGHS 
SUPPLY  CHANNELS  AND 
EDUCATIONAL  SOURCES 
(WITH  GREAT 
DIFFICULTY) 

CLASSROOM 

REQUIREMENTS 

LOCAL  PURCHASE 
(PRIVATELY  OWNED) 

AAAAA 

ASD  CONTRACT 

GOVT  PURCHASE 

DO  NOT  KNOW 

ASD  CONTRACT 

ASD  ISTC  SMALL 
COMPUTER  CONTRACT 

PERFECT  CALC 

CCCCC 

QUATRO 

CCCCC 

MAINFRAME  BURROUGHS 

CLASSROOM 

REQUIREMENTS 

SUPERCALC  3 

BBBBB 

SUPERCALC 

CCCCC 

MAINFRAME  BURROUGHS 

Ill 
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sw 

TYPE 


PRODUCT 

NAME 


UNIT 


HOW 

ACQUIRED 


VP  PLANNER  CCCCC  MAINFRAME  BURROUGHS 

SUPPLY  CHANNELS  AND 
EDUCATIONAL  SOURCES 
(WITH  GREAT 
DIFFICULTY) 

CLASSROOM 
REQUIREMENTS 
ACQUIRED  AS 
EVALUATION  COPY  FROM 
COMPANY 

ST  BASS  CCCCC  PURCHASE  THROUGH 

CCCCC 

MATHCAD  CCCCC  PURCHASE  THROUGH 

CCCCC 


MICROSTAT  CCCCC  GSA  ZENITH  CONTRACT 

FORM  9  (WITH  GREAT 
DIFFICULTY) 


POWERPACK 

CCCCC 

PURCHASE 

CCCCC 

THROUGH 

MULT I MATE 

CCCCC 

MAINFRAME 

BURROUGHS 

PEACHTEXT 

CCCCC 

MAINFRAME 

BURROUGHS 

• 

AAAAA 

STANDARD  ZENITH 
CONTRACT 

ASD  CONTRACT 

VOLKSWRITER- 

3 

CCCCC 

MAINFRAME 

BURROUGHS 

WORDPERFECT 

CCCCC 

PERSONAL 

PURCHASE 

WORDSTAR 

BBBBB 

STANDARD 

CONTRACT 

ZENITH 

STANDARD 

CONTRACT 

ZENITH 

CCCCC 

MAINFRAME 

BURROUGHS 

CAME  WITH  SYSTEM 
ACQUISITION 
SEAT  OF  THE 
PANTS ; INTUITION 
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sw 

PRODUCT 

HOW 

TYPE 

NAME 

UNIT 

ACQUIRED 

SMALL  COMPUTER 
CONTRACT 

WRITE  ONE 

ccccc 

MAINFRAME  BURROUGHS 

WRITESOFT 

BBBBB 

LOCAL  PURCHASE  ( AF ) 
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Appendix  6:  How  Software  Needs  Were  Determined 


SW  PRODUCT 

TYPE  NAME  UNIT 

CO  COORDINATOR  CCCCC 

MS-KERMIT  CCCCC 

PROCOMM  CCCCC 

SMART  TERM  CCCCC 

240 

Z  STEM  CCCCC 

AAAAA 

ZSTEM  CCCCC 

DB  CONDOR  BBBBB 


CCCCC 

D  BASE  III+  BBBBB 

DBASE  BBBBB 

II ; DBASEIII 

DBASE  III  BBBBB 


HOW  NEED 
WAS 

DETERMINED 

STUDENT  REQUIREMENT 
ASSESSMENT 

TRANSPORTABILITY ; 
INTEROPERABILITY; 
COMMUNICATION 

COMMUNICATION; 

INTEROPERABILITY 

GRAPHICS 


COMMUNICATION; 

INTEROPERABILITY 

COMMUNICATION 

CAME  WITH 
SYSTEM; STANDARD 
ZENITH  CONTRACT 

TRIAL  AND  ERROR 
AFTER  REVIEWING 
OTHER  PACKAGES 

INTEROPERABILITY ; 
TRANSPORTABILITY 

TRIAL  AND  ERROR 
AFTER  REVIEWING 
OTHER  PACKAGES 

I NTEROPERAB I L I T Y ; 
TRANSPORTABILITY ; 
MONITORING/CONTROL 

MONITORING/CONTROL ; 
ORGANIZING/SCHEDULING 
NEEDED  A  DATABASE 
MGMT  SYS  AND  AFLC 
ISTC  RECOMMEND  PKG 
INTEROPERABILITY 
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SW  PRODUCT 

TYPE  NAME  UNIT 

CCCCC 

AAAAA 

DBASE  I 11+  BBBBB 

CCCCC 

MICROX  BBBBB 

PARTS  MASTER  BBBBB 

GR  CHART  BBBBB 

AAAAA 

HARVARD  CCCCC 

GRAPHICS 


HOW  NEED 
WAS 

DETERMINED 


TASKS  PRESENTLY 
USING  SS  APPLICATION 
(VP  PLANNER) 
DIAGNOSIS/PROBLEM 
FINDING 

REQUIRED ; MONITORING/ 
CONTROL 

LOW  PRICE  AT  TIME  OF 
HARDWARE  PURCHASE  VS 
HI  $  LATER 

ORGANIZING/SCHEDULING 

MONITORING/CONTROL 

DIAGNOSIS/PROBLEM 
FINDING; ORGANIZING/ 
SCHEDULING ; MONITORING/ 
CONTROL 


ANALYSIS  HAD  IT  AND 
WE  FOUND  IT 
SATISFACTORY 
FREE  PRODUCT; 

APPLICATION  REQUIRED 

BRIEFINGS ; AUTHORING/ 
PRESENTATION 

AUTHORING/PRESENTATION 

AUTHORING/PRESENTATION 

OBTAINED 

DEMOS ; REVIEWED 

PRODUCTS/SPECS 

DEFINED  NEED  FOR  GRAPHICS 

PACKAGE ; EVALUATED  OTHERS 

FIRST 

LOW  PRICE  AT  TIME  OF 
HARDWARE  PURCHASE  VS 
HI  $  LATER 

AUTHORING/PRESENTATION 

AUTHORING/PRESENTATION 

AUTHORING/PRESENTATION 


111 


HOW  NEED 

SW 

PRODUCT 

WAS 

TYPE 

NAME 

UNIT 

DETERMINED 

AUTHORING/PRESENTATION 
DEMONSTRATION ; EVALUATION 
AUTHORING/PRESENTATION 

IT  ABILITY  CCCCC  STUDENT  INSTRUCTION 

AIDE 

ENABLE  CCCCC  OBTAINED 

DEMOS; REVIEWED 
PRODUCTS /SPECS 
CAME  WITH 
SYSTEM ; STANDARD 
ZENITH  CONTRACT 
FIXED  FIELD  DB>80 
COLUMNS; THESIS 
ADMIN ; BOOLEAN 
SEARCH /STORAGE 

AAAAA  COST ;  STANDARD 

ZENITH  CONTRACT  ITEM 
NO 

DETERMINATION ; PRODUCT 
REVIEWS  IN  PC  MAGAZINE 
MANDATED  BY  ASD 
TRANSPORTABILITY ; 
INTEROPERABILITY; 
COMMUNICATION ; AUTHORING 
PRESENTATION 


OT 

QBS 

CCCCC 

DIAGNOSIS/PROBLEM 
FINDING ; PLANNING/ 
DECISION  MAKING 

PL 

BASIC 

AAAAA 

TRANSPORTABILITY ; 
INTEROPERABILITY 

PM 

EXPERT 

SYSTEM 

CCCCC 

- 

TIMELINE 

CCCCC 

OBTAINED 

DEMOS; REVIEWED 
PRODUCTS/SPECS 


SW  PRODUCT 

TYPE  NAME  UNIT 

SS  LOTUS  123  BBBBB 

CCCCC 


AAAAA 


PERFECT  CALC  CCCCC 
QUATRO  CCCCC 

SUPERCALC  3  BBBBB 

SUPERCALC  CCCCC 

III 


HOW  NEED 
WAS 

DETERMINED 


HQ  AFLC  DIRECTED 

CAME  WITH  SYSTEM 
( BUNDLED ) 

AUTHORING/PRESENTATION 

LOW  PRICE  AT  TIME  OF 
HARDWARE  PURCHASE  VS 
HI  $  LATER 

AUTHORING/PRESENTATION 
DIAGNOSIS/PROBLEM 
FINDING; PLANNING/ 
DECISION  MAKING 

CONSULTING  USERS  AND 
OTHER  ORGANIZATIONS 
TIMELINE  ANALYSIS  OF 
SYSTEM; SIMULATION 
FACT  FINDING  DURING 
EVALUATIONS 
DIAGNOSIS/PROBLEM 
FINDING; SYSTEM 
DEVELOPMENT 
FRUSTRATED  WITH 
DBMS/ENABLE; LIT 
REVIEW ; TRANSPORTABILITY 
TRANSPORTABILITY; 
INTEROPERABILITY; 
DIAGNOSIS/PROBLEM 
FINDING 


CAME  WITH  SYSTEM 
( BUNDLED ) 

LOW  PRICE  AT  TIME  OF 
HARDWARE  PURCHASE  VS 
HI  $  LATER 

ANALYSIS  ORDERED  IT 
TO  INCREASE 

SPREADSHEET  CAPABILITY 

CAME  WITH  SYSTEM 
(BUNDLED) 


HOW  NEED 

SW  PRODUCT  WAS 

TYPE  NAME  UNIT  DETERMINED 


VP  PLANNER  CCCCC  CAME  WITH  SYSTEM 

( BUNDLED ) 

AUTHORING/PRESENTATION 

LOW  PRICE  AT  TIME  OF 
HARDWARE  PURCHASE  VS 
HI  $  LATER 
MANAGEMENT/CONTROL ; 
AUTHORING/PRESENTATION 


ST 

BASS 

CCCCC 

STUDENT  REQUIREMENT 
ASSESSMENT 

MATHCAD 

CCCCC 

MICROSTAT 

CCCCC 

AUTHORING/PRESENTATION 

DIAGNOSING/PROBLEM 

FINDING 

AUTHORING/PRESENTATION 

DIAGNOSIS/PROBLEM 

FINDING 

POWERPACK 

CCCCC 

STUDENT  REQUIREMENT 
ASSESSMENT 

WP 

MULTIMATE 

CCCCC 

PEACHTEXT 

CCCCC 

AAAAA 

STANDARD  CONTRACT 

VOLKSWRITER- 

3 

CCCCC 
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sw 

TYPE 


PRODUCT 

NAME 


UNIT 


HOW  NEED 
WAS 

DETERMINED 


WORDPERFECT 

WORDSTAR 


WRITE  ONE 

WRITESOFT 


CCCCC  INTEROPERABILITY 

TRANSPORTABILITY ; 
AUTHOR I NG / PRESENT AT I ON 

BBBBB  MONITORING/CONTROL 

AUTHORING/PRESENTATION 


CCCCC 

ADMIN  CORRESPONDENCE 
AUTHORING/PRESENTATION 
INTEROPERABILITY 
AUTHORING/PRESENTATION 


CCCCC  CAME  WITH  SYSTEM 

( BUNDLED ) 

BBBBB  PERSONAL 

PREFERENCE ; APPLICATION 
REQUIRED 


Appendix  7:  Task  Analysis 


sw 

TYPE 

INTENDED 

TASKS 

TASKS 

STREAMLINED 

TASKS 

NOT 

STREAMLINED 

CO 

COMMUNICATION 

COMMUNICATION 

COMMUNICATION; 

T  RAN  S  PORT AB I L I T Y 

COMMUNICATION 

EFFECTIVE 
USE  OF  HW 
(PRINTERS) 

COMMUNICATION 

INTEROPERABILITY 

COMMUNICATION 

COMMUNICATION 

TRANSPORTABILITY 

INTEROPERABILITY 

ALL 

ALL 

COMMUNICATION 

NONE 

COMMUNICATIONS; 

INTEROPERABILITY 

ALL 

NONE 

DB 

ORGANIZING/ 

SCHEDULING; 

ALL 

NONE 

MONITORING/CONTROL 

MONITORING/ 

MONITORING/ 

CONTROL 

CONTROL 

ORGANIZING/ 

ORGANIZING/ 

SCHEDULING 

SCHEDULING; 

MONITORING/ 

MONITORING/ 

CONTROL 

CONTROL 

ORGANIZING/ 

ORGANIZING/ 

NONE. 

SCHEDULING 

SCHEDULING 

MONITORING 

MONITORING 

CONTROL 

CONTROL 

DIAGNOSIS/ 

DIAGNOSIS/ 

NONE. 

PROBLEM  FINDING 

PROBLEM  FINDING 

AUTHORING/ 

AUTHORING/ 

PRESENTATION 

PRESENTATION 

MONITORING 

ALL 

CONTROL 

MONITORING/ 

ALL  PLUS  T/A 

CONTROL 

LOG 

MONITORING 

MONITORING/ 

CONTROL 

CONTROL 

ORGANIZING/ 

ORGANIZING/ 

SCHEDULING 

SCHEDULING ; MONITORING 

CONTROL ; DI AGNOS I S 
PROBLEM  FINDING 


116 


sw 

TYPE 


INTENDED 

TASKS 


TASKS 

STREAMLINED 


TASKS 

NOT 

STREAMLINED 


GR 


MONITORING/ 

ENDLESS 

CONTROL 

LIST; POST  TO 
POST 

TRANSACTIONS 

MONITORING/CONTROL 

ORGANIZING/ 

SCHEDULING 

STILL  UNDER 
DEVELOPMENT 

AUTHORING/ 

ALL 

NONE 

PRESENTATION; 

MONITORING/CONTROL 

DIAGNOSIS/ 
PROBLEM  FINDING 
MONITORING/ 

ALL 

CONTROL 

DIAGNOSIS/ 
PROBLEM  FINDING 

AUTHORING/ 

AUTHORING/ 

PRESENTATION 

PRESENTATION 

AUTHORING/ 

ALL,  BUT  TAKES 

ALL  TASKS 

PRESENTATION 

MORE  INDIVIDUAL 

TAKE  MORE 

TIME; COMPOSING 

PERSONNEL 

TIME  +  MANUAL 

TIME  DUE  TO 

TASKS ; ELEMENT 

COMPOSITION 

OF  EFFICIENCY 

BUT  THAT  IS 

AND 

NOT 

EFFECTIVENESS; 

NECESSARILY 

AUTHORING; 

PRESENTATION 

BAD 

AUTHORING/ 

AUTHORING/ 

NONE 

PRESENTATION 

PRESENTATION 

AUTHORING/ 

AUTHORING/ 

PRESENTATION 

PRESENTATION 

BRIEFING; 

AUTHORING/ 

PRESENTATION 

ALL 

AUTHORING/ 

PRESENTATION 

ALL 

NONE 

AUTHORING/ 

PRESENTATION 

ALL 

NONE 

AUTHORING/ 

PRESENTATION 

ALL 

AUTHORING/ 

AUTHORING/ 

NONE 

PRESENTATION 

PRESENTATION 
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sw 

TYPE 


INTENDED 

TASKS 


TASKS 

STREAMLINED 


TASKS 

NOT 

STREAMLINED 


AUTHORING/ 

AUTHORING/ 

NONE 

PRESENTATION 

PRESENTATION 

AUTHORING/ 

ALL 

PRESENTATION 

AUTHORING/ 

ALL 

PRESENTATION 

AUTHORING/ 

ALL 

NONE. 

PRESENTATION 

AUTHORING/ 

AUTHORING/ 

PRESENTATION; 

PRESENTATION; 

INTEROPERABILITY 

INTEROPERABILITY 

TRANSPORTABILITY 

TRANSPORTABILITY 

AUTHORING/ 

AUTHORING/ 

PRESENTATION 

PRESENTATION 

AUTHORING/ 

AUTHORING/ 

N/A 

PRESENTATION; 

PRESENTATION 

DIAGNOSIS/PROBLEM 

FINDING 

MONITORING/ 

MONITORING/ 

AUTHORING/ 

CONTROL 

CONTROL 

PRESENTATION 

INTEROPERABILITY 

INTEGRATION 

TRANSPORTABILITY 

OF  SS  AND  WP 

TASKS ; MAY  BE 
DUE  TO  HW 
INCOMPATIBILITY 
AND  A  LACK  OF 
TRAINING; 
INTEROPERABILITY 

MONITORING/CONTROL 

ORGANIZING/ 

SCHEDULING; 

AUTHORING/ 

PRESENTATION 

AUTHORING/  AUTHORING/ 

PRESENTATION  PRESENTATION 

DIAGNOSIS/  ALL 

PROBLEM  FINDING 

AUTHORING 

PRESENTATION 

AUTHORING/  ALL 

PRESENTATION 

AUTHORING/  ALL 

PRESENTATION; 

INTEROPERABILITY 

TRANSPORTABILITY 


118 


OT 


TASKS 

sw 

INTENDED 

TASKS 

NOT 

TYPE 

TASKS 

STREAMLINED  STREAMLINED 

AUTHORING/ 

AUTHORING/ 

GOVT  VERSION 

PRESENTATION; 

PRESENTATION; 

INADEQUATE; 

INTEROPERABILITY 

INTEROPERABILITY 

PERSONAL  VERSION 

D I AGNOS I S/PROBLEM 

SATISFIES 

FINDING; 

TASKS ; PERSONAL 

T  RAN  SPORT AB I L I TY 

VERSION 

UPGRADED  AND 

PRIVATELY 

PURCHASED 

PLANNING/ 

ALL,  BUT  TAKES 

ALL  TASKS 

DECISION 

MORE  INDIVIDUAL 

TAKE  MORE 

MAKING; DIAGNOSIS 

TIME; COMPOSING 

PERSONNEL 

PROBLEM 

TIME  +  MANUAL 

TIME  DUE  TO 

FINDING 

TASKS ; ELEMENT 

COMPOSITION 

OF  EFFICIENCY 

BUT  THAT  IS 

AND 

NOT 

EFFECTIVENESS 

NECESSARILY 

BAD 

PL 

NONE 

NONE 

PM 

MONITORING/ 

MONITORING/ 

NONE 

CONTROL ; SYSTEM 

CONTROL; SYSTEM 

DEVELOPMENT 

DEVELOPMENT 

ALL 

ALL  TASKS 

TAKE  MORE 
PERSONNEL 

TIME  DUE  TO 
COMPOSITION 

BUT  THAT  IS 

NOT 

NECESSARILY 

BAD 

SS 

PLANNING/ 

TRANS  PORTAB I L I TY 

DECISION 

INTEROPERABILITY 

MAKING; 

PLANNING/DECISION 

MONITORING/ 

MAKING 

CONTROL 

MONITORING 

CONTROL 

• 

AUTHORING/ 

MINIMAL 

PRESENTATION 

SUCCESS 

INTEROPERABILITY 

INTEROPERABILITY 

NONE 

MONITORING/ 

MONITORING/ 

CONTROL;  CONTROL; ORGANIZING 

SCHEDULING; 
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sw 

TYPE 


TASKS 

INTENDED  TASKS  NOT 

TASKS  STREAMLINED  STREAMLINED 


TRANSPORTABILITY 
PLANNING/  ALL 

DECISION 

MAKING {DIAGNOSIS 
PROBLEM 
FINDING 
DIAGNOSIS/ 

PROBLEM  FINDING 
NONE ; SAW 
APPLICATIONS 
AFTER  SW 
ACQUIRED 
AUTHORING/ 

PRESENTATION 
AUTHORING/ 

PRESENTATION 
AUTHORING/ 

PRESENTATION 


DIAGNOSIS/ 

PROBLEM 
FINDING ; MONITORING 
CONTROL 

MONITORING/  MONITORING/  N/A 

CONTROL  CONTROL 

AUTHORING/  ALL 

PRESENTATION 
MONITORING/CONTROL 
AUTHORING/  ALL 

PRESENTATION 
DIAGNOSIS/PROBLEM 
FINDING {PLANNING 
DECISION 
MAKING 

AUTHORING/  ALL 

PRESENTATION 
MONITORING/CONTROL 
AUTHORING/  ALL 

PRESENTATION 
MONITORING/CONTROL 
MONITORING/  MONITORING/  NONE 

CONTROL  CONTROL 

DIAGNOSIS/  ALL 

PROBLEM  FINDING 


NONE 

NONE 

NONE 

NONE. 


ALL 

DIAGNOSIS/  NONE 

PROBLEM 

FINDING; SYSTEM 
DEVELOPMENT 

MINIMAL 

SUCCESS 

MINIMAL 

SUCCESS 

MINIMAL 

SUCCESS 

PLANNING/DECISION 

MAKING 

ALL  NONE . 
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sw 

TYPE 


INTENDED 

TASKS 


TASKS 

STREAMLINED 


TASKS 

NOT 

STREAMLINED 


AUTHORING/  ALL 

PRESENTATION 

MONITORING/CONTROL 

NONE 

ST 

DIAGNOSIS/ 
PROBLEM  FINDING 

ALL 

NONE 

AUTHORING/ 

ALL 

NONE 

PRESENTATION 

PRESENTATION 

AUTHORING/ 

ALL 

NONE 

DIAGNOSING/ 
PROBLEM  FINDING 

ALL 

NONE 

WP 

AUTHORING/ 

PRESENTATION 

ALL 

AUTHORING/ 

AUTHORING/ 

GOVT  VERSION 

PRESENTATION 

PRESENTATION; 

INADEQUATE ; 

TRANSPORTABILITY  PERSONAL 

VERSIONS 

SATISFY 

TASKS ; PERSONAL 

VERSIONS  ARE 

UPGRADED 

VERSIONS  AND 

PRIVATELY 

PURCHASED; 

INTEROPERABILITY 


AUTHORING/ 

PRESENTATION 

MONITORING/ 

CONTROL 

AUTHORING/ 

PRESENTATION 

AUTHORING/ 

PRESENTATION 


AUTHORING/ 

PRESENTATION 

AUTHORING/ 

PRESENTATION 

AUTHORING/ 

PRESENTATION 

AUTHORING/ 

PRESENTATION 


AUTHORING/ 

PRESENTATION 

MONITORING/ 

CONTROL 

AUTHORING/ 

PRESENTATION 

FUTURE  TASKS 


ALL 

AUTHORING/ 

PRESENTATION 

AUTHORING/ 

PRESENTATION 

AUTHORING/ 

PRESENTATION 


N/A 


ADMIN 

CORRESPONDENCE 

AUTHORING/ 

PRESENTATION 


121 


sw 

TYPE 


INTENDED 

TASKS 


TASKS 

STREAMLINED 


TASKS 

NOT 

STREAMLINED 


AUTHORING/  AUTHORING/ 

PRESENTATION  PRESENTATION 

INTEROPERABILITY  ALL 


AUTHORING/ 

PRESENTATION 

AUTHORING/ 

PRESENTATION 

AUTHORING/ 

PRESENTATION 

MONITORING 

CONTROL 

AUTHORING/ 

PRESENTATION 


AUTHORING/ 

PRESENTATION 

AUTHORING/ 

PRESENTATION 


ALL 


DESKTOP 

PUBLISHING 
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Appendix  8:  User  Satisfaction  with  Software  Products 


sw 

PRODUCT 

TYPE 

UNIT 

NAME 

SATISFACTION 

CO 

CCCCC 

COORDINATOR 

Y 

MS-KERMIT 

N 

PROCOMM 

N 

SMART  TERM 

240 

Y 

Z  STEM 

N 

ZSTEM 

AAAAA 

Z  STEM 

Y 

DB 

BBBBB 

CONDOR 

Y 

D  BASE  III+ 

Y 

DBASE  II 

Y 

DBASE  III 

Y 

Y 

Y 

DBASE  III+ 

Y 

MICROX 

Y 

PARTS  MASTER 

Y 

Y 

Y 

CCCCC 

CONDOR 

DBASE  III 

DBASE  III+ 

Y 

AAAAA 

DBASE  III 

Y 

GR 

BBBBB 

CHART 

Y 

Y 

Y 

CCCCC 

HARVARD 

Y 

123 


SW  PRODUCT 

TYPE  UNIT  NAME  SATISFACTION 


GRAPHICS 

Y 

Y 

Y 

Y 

Y 

Y 

Y 
N 

Y 

Y 

AAAAA  CHART  Y 

Y 

IT  CCCCC  ABILITY  N 

ENABLE  Y 

N 

Y 

AAAAA  ENABLE  Y 

Y 
N 

Y 


OT 

CCCCC 

QBS 

Y 

PL 

AAAAA 

BASIC 

Y 

PM 

CCCCC 

EXPERT 

Y 

SYSTEM 

TIMELINE 

Y 

SS 

BBBBB 

LOTUS  123 

Y 

Y 

SUPERCALC  3 

Y. 

CCCCC 

LOTUS  123 

Y 

Y 

Y 

Y 


PERFECT  CALC 
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SW  PRODUCT 

TYPE  UNIT  NAME 


QUATRO 


SUPERCALC 

III 

VP  PLANNER 


AAAAA  LOTUS  123 


ST  CCCCC  BASS 

MATHCAD 

MICROSTAT 

POWERPACK 

WP  BBBBB  WORDSTAR 

WRITESOFT 

CCCCC  MULTIMATE 

PEACHTEXT 

VOLKSWRITER- 

3 

WORDPERFECT 

WORDSTAR 


WRITE  ONE 


SATISFACTION 


Y 

Y 

Y 


Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 


Y 

Y 
N 
N 
N 

Y 
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sw 

TYPE 


PRODUCT 

UNIT  NAME 


AAAAA  PEACHTEXT 


SATISFACTION 


Y 

Y 
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Appendix  9:  Product  Comparisons 


sw 

PRODUCT 

PRODUCT 

TYPE 

UNIT 

NAME 

COMP 

CO 

CCCCC 

COORDINATOR 

MS-KERMIT 

NO 

CONTROLLED 
STUDY  WAS 
DONE 

PROCOMM 

NO 

CONTROLLED 
STUDY  WAS 
DONE 

SMART  TERM 
240 

PROCOMM 

Z  STEM 

NO 

CONTROLLED 
STUDY  WAS 
DONE 

ZSTEM 

AAAAA 

Z  STEM 

PROCOMM 

DB 

BBBBB 

CONDOR 

NONE. 

D  BASE  III+ 

NONE. 

DBASE 

II ; DBASEIII 

DBASE  III 

PEACHTEXT 

NONE 

ENABLE 


REASON  FOR 
CHOICE 


NOT  A 

CONTROLLED 
SEARCH ; 
GRASPING  AT 
STRAWS ; 
EVALUATION 

NOT  A 

CONTROLLED 
SEARCH ; 
GRASPING  AT 
STRAWS ; 


NOT  A 

CONTROLLED 
SEARCH ; 
GRASPING  AT 
STRAWS ; 


PROCOMM  USED 
FOR. ACCESS 
FROM  HOME 


WORKSHOP 
RECOMM ; 
SEMINARS; LIT 
REVIEWS 
STANDARD 
ZENITH 
CONTRACT 
ENABLE  WOULD 
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sw 

YPE 


UNIT 


PRODUCT 

NAME 


PRODUCT 

COMP 


REASON  FOR 
CHOICE 


NOT  MEET 
REQUIREMENTS 
DBASE  IS 
MORE 

POWERFUL 

DBASE  I 11+  NONE; PUBLIC  ON  STANDARD 
DOMAIN  CONTRACT 

SOFTWARE 
HINDERED 
BY  LEGAL 
IMPLICATIONS 


MICROX  NONE.  USER 

FRIENDLY; 

SATISFIED 

REQUIREMENT; 

EASY 

TRAINING 

PARTS  MASTER 

NONE. 

NONE .  USER 

FRIENDLY; 

SATISFIED 

REQUIREMENT; 

EASY 

TRAINING 

CCCCC  CONDOR  WORD 

PROCESSING 
IN  DOS  WAS 
KEY 

DBASE  III  NONE  PERSONAL 

KNOWLEDGE  OF 
CAPABILITIES 

DBASE  I 11+  NO  COMPATIBLE 

COMPETITION  WITH  REST  OF 
EDUCATION  AF/ACADEMIC 
WORLD 

CONSIDERATION 

WAS 

THE  MAIN 
DRIVER 


128 


sw 

TYPE 


GR 


PRODUCT 

PRODUCT 

REASON  FOR 

UNIT 

NAME 

COMP 

CHOICE 

AAAAA 

DBASE  III 

NONE 

BBBBB 

CHART 

NONE; PUBLIC 

ON  STANDARD 

DOMAIN 

SOFTWARE 

HINDERED 

BY  LEGAL 

CONTRACT 

IMPLICATIONS 

NONE. 

HAD  NO  OTHER 
CHOICES 

CCCCC 

HARVARD 

CHART 

USER 

GRAPHICS 

NONE 

INTERFACE; 
EASE  OF 

USE ; EXCELLENT 
OUTPUT 

BASED  ON 
PERSONAL 
PRODUCT 
EVALUATION 

CHART 

MORE 

FRIENDLY; 

MORE 

OPTIONS; EASE 
OF  USE 

CHART 

USER 

PRESEN- 

INTERFACE ; 

TAT IONS 

QUALITY  OF 
OUTPUT 

ENABLE 

EASY  TO 

LEARN 

NO 

NONE 

NOT  A 

CONTROLLED 
SEARCH ; 
GRASPING  AT 
STRAWS ; 
EVALUATION 

SLIDEMASTER 

QUALITY 

CHART 

UTILITY  AND 
PRICE; DOES 

JOB  BETTER 

AND  EASIER 

AAAAA  CHART  NONE 
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sw 

TYPE 

UNIT 

PRODUCT 

NAME 

PRODUCT 

COMP 

REASON  FOR 
CHOICE 

IT 

CCCCC 

ABILITY 

ENABLE ; 
FRAMEWORK 
OPEN  ACCESS 

ONLY  ONE 
WHICH  COULD 
SATISFY 
REQUIREMENT 
(HOT  LINKS) 

ENABLE 

WORD 

PERFECT ; 
DBASE  III 
LOTUS  123 

COST ; 

AVAILABILITY 

PERFECT 

FILER 

LOTUS  123 

TRANSPORTABI 

LITY 

AAAAA 

ENABLE 

WORDSTAR; 

MULTIMATE 

USE  ALL  DUE 
SO  LONG  AS 

CAN 

CREATE/ 
RECEIVE  ASCII 
FILES 

NONE; 

MANDATED 

BY  HQ 

NONE ; NO 

OTHER 

INTEGRATED 

PACKAGES 

AVAILABLE 


OT 

CCCCC 

QBS 

NONE 

QUALITY; FREE 

PL 

AAAAA 

BASIC 

NONE 

PM 

CCCCC 

EXPERT 

SYSTEM 

TIMELINE 

HARVARD 

TPM ; SUPER 

PROJECT 

EXPERT 

STANDARD 

ZENITH 

CONTRACT  MET 
NEED 

SS 

BBBBB 

LOTUS  123 

NONE. 

HAD  NO  OTHER 
CHOICES 

SUPERCALC  3 

NONE. 

HAD  NO  OTHER 

CHOICES 
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sw 

TYPE 


PRODUCT 

PRODUCT 

REASON  FOR 

UNIT 

NAME 

COMP 

CHOICE 

CCCCC 

LOTUS  123 

NO  OTHER 
CHOICES 
DBASE  III 

SS  MET 

DATA  BASE 

REQUIREMENTS 

MANAGEMENT 

DBMS  WOULD 

SYSTEM 

HAVE  BEEN 
OVERKILL 

MULT I PLAN 

BETTER 

BASED  ON 

SUPPORT  AND 

STUDENT 

DOCUMENTATION 

SUPPORT 

I.E.  LOTUS 

AND  COST 

MAGAZINE 

ARTICLES 

NO 

INTEROPERABI¬ 
LITY;  TRANS¬ 
PORTABILITY 

QUATRO 

NO  OTHER 
CHOICES 

SUPERCALC 

NO  OTHER 

III 

CHOICES 

VP  PLANNER 

NO  OTHER 
CHOICES 

NONE 

PERSONAL 
KNOWLEDGE  OF 
CAPABILITIES 

AAAAA 

LOTUS  123 

NONE; NO 
OTHER  MET 

REQUIREMENTS 

MS-EXCELL; 

LITERATURE/ 

BOENG  CALC 

TRAINING 
AVAILABILITY 
COMPATIBILITY 
KNOWLEDGE 
CONCENTRATED 
ON  TIME 
LEARNING  NEW 
PACKAGE 

SUPERCALC ; 

LITERATURE 

VP  PLANNER 

AVAILABILITY 

DECALC 

COMPATIBILITY 

PORTABILITY 

EASE 
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sw 

TYPE  UNIT 


ST  CCCCC 


WP  BBBBB 


CCCCC 


SW 

TYPE  UNIT 


PRODUCT 

PRODUCT 

REASON  FOR 

NAME 

COMP 

CHOICE 

BASS 

STATISTIX 

FULLY 

STAT- 

SATISFIED 

GRAPHICS; 

REQUIREMENT 

MICROSTAT; 

AND 

TASKS  = 

REASONABLY 

STUDENT 

AIDS 

ISP; ICS 

PRICED 

MATHCAD 

STATISTIX 

FULLY 

STAT- 

SATISFIED 

ISP; ICS 

REQUIREMENT 

MICROSTAT; 

AND 

TASKS  = 

REASONABLY 

STUDENT 

AIDS 

PRICED 

MICROSTAT 

NO 

STAT- 

MET  REQ  AND 

GRAPHICS 

ALREADY  ON 

AS; SPSS/PC 

ZENITH 

CONTRACT; LESS 
EXPENSIVE 

POWERPACK 

STATISTICS 

FULLY 

STAT- 

SATISFIED 

GRAPHICS ; 

REQUIREMENT 

MICROSTAT; 
ISP; ICS 

AND 

TASKS  = 

REASONABLY  . 

STUDENT 

AIDS 

PRICED 

WORDSTAR 

NONE 

STANDARD 

ZENITH 

CONTRACT 

WRITESOFT 

NONE; PUBLIC 

ON  STANDARD 

DOMAIN  CONTRACT 

SOFTWARE 

HINDERED 

BY  LEGAL 

IMPLICATIONS 

MULT I MATE 

NO  OTHER 
CHOICES 

PRODUCT 

PRODUCT 

REASON  FOR 

NAME 

COMP 

CHOICE 
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AAAAA 


PEACHTEXT 

VOLKSWRITER- 

3 

NO  OTHER 
CHOICES 

NO  OTHER 
CHOICES 

WORDPERFECT 

WORDSTAR 

WORDSTAR 

NO  OTHER 
CHOICES 

NO 

CONTROLLED 
STUDY  WAS 
DONE 

MAINFRAME 

SYSTEM 

WORD 

PERFECT ; MS 

WORD ; PC 

WRITE; 

VOLKS 

WRITER 

MULTIMATE 

WRITE  ONE 

NO  OTHER 
CHOICES 

PEACHTEXT 


COMPATIBILITY 


NOT  A 

CONTROLLED 
SEARCH ; 
GRASPING  AT 
STRAWS ; 
EVALUATION 
TRANSPORTA¬ 
BILITY 

FORMAT; TRANS¬ 
PORTABILITY; 
STUDENTS 
WERE 
FAMILIAR 
WITH  IT 


NONE; 

STANDARD 

CONTRACT 


Appendix  10:  Recurring  Tasks  Simplified  By  Software 


sw 

DAILY 

QUARTERLY 

ANNUAL 

TYPE 

TASKS 

TASKS 

TASKS 

CO 

COMMUNICATION 

ORGANIZING 

SCHEDULING 

COMMUNICATION 

COMMUNICATION 

INTEROPERABILITY 

DB 

ORGANIZING/ 

MONITORING/ 

MONITORING/ 

SCHEDULING 

CONTROL 

CONTROL 

DIAGNOSIS/ 

AUTHORING/ 

PROBLEM 

PRESENTATION 

FINDING 

MONITORING/ 

CONTROL 

MONITORING/ 

CONTROL 

MONITORING/ 

DIAGNOSIS/ 

AUTHORING/ 

CONTROL ; 

PROBLEM 

PRESENTATION 

ORGANIZING/ 

FINDING 

SCHEDULING 

ORGANIZING/ 

MONITORING/ 

SCHEDULING; 

MONITORING 

CONTROL 

CONTROL 

ORGANIZING/ 

MONITORING/ 

SCHEDULING; 

MONITORING/ 

CONTROL 

CONTROL 

ORGANIZING/ 

MONITORING/ 

MONITORING/ 

SCHEDULING; 

DIAGNOSIS/ 

CONTROL 

CONTROL 

PROBLEM  FINDING 

ALL 

DIAGNOSIS 

DIAGNOSIS/ 

PROBLEM 

PROBLEM 

FINDING 

FINDING 

ORGANIZING/ 

MONITORING/ 

AUTHORING/ 

SCHEDULING; 

CONTROL ; 

PRESENTATION 

MONITORING/ 

AUTHORING/ 

CONTROL 

PRESENTATION 

GR 

AUTHORING/ 

AUTHORING/ 

AUTHORING/ 

PRESENTATION 

PRESENTATION 

PRESENTATION 
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sw 

TYPE 


DAILY 

TASKS 


QUARTERLY 

TASKS 


ANNUAL 

TASKS 


AUTHORING  AUTHORING 

PRESENTATION  PRESENTATION 
AUTHORING 
PRESENTATION 
AUTHORING  AUTHORING 

PRESENTATION  PRESENTATION 
AUTHORING 
PRESENTATION 

AUTHORING 

PRESENTATION 

AUTHORING 

PRESENTATION 

AUTHORING  AUTHORING 

PRESENTATION  PRESENTATION 

AUTHORING 

PRESENTATION 

AUTHORING 

PRESENTATION 

MONITORING/ 

CONTROL 

AUTHORING 

PRESENTATION 

IT  DIAGNOSIS/ 

PROBLEM 

FINDING 

AUTHORING 

PRESENTATION; 

MONITORING/ 

CONTROL ; 

ORGANIZING/ 

SCHEDULING 

AUTHORING  AUTHORING 

PRESENTATION  PRESENTATION 
AUTHORING  MONITORING/ 

PRESENTATION  CONTROL 

MONITORING/ 

CONTROL 


AUTHORING  AUTHORING 
PRESENTATION  PRESENTATION; 


AUTHORING/ 

PRESENTATION 


MONITORING/ 

CONTROL 


DIAGNOSIS/ 

PROBLEM 

FINDING 


MONITORING/ 

CONTROL 

AUTHORING 

PRESENTATION 

MONITORING/ 

CONTROL 

DIAGNOSIS/ 

PROBLEM 

FINDING 
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sw 

DAILY 

QUARTERLY 

ANNUAL 

TYPE 

TASKS 

TASKS 

TASKS 

MONITORING/ 

CONTROL 

OT 

PL 

TRANSPORTABILITY 

INTEROPERABILITY 

PM 

MONITORING/ 

SYSTEM 

CONTROL; SYSTEM 

DEVELOPMENT 

DEVELOPMENT 

SS 

DIAGNOSIS/ 

DIAGNOSIS/ 

PROBLEM 

PROBLEM 

FINDING 

FINDING 

DIAGNOSIS/ 

AUTHORING 

PROBLEM 

FINDING; 

PLANNING 

PRESENTATION 

DECISION  MAKING 

DIAGNOSIS/ 

PROBLEM 

FINDING; 

SYSTEM 

DEVELOPMENT 

MONITORING/ 

MONITORING 

MONITORING 

CONTROL 

CONTROL 

CONTROL 

AUTHORING 

AUTHORING 

PRESENTATION; 

PRESENTATION 

MONITORING/ 

CONTROL 

DIAGNOSIS/ 

PROBLEM 

SOLVING 

ORGANIZING/ 

MONITORING 

SCHEDULING 

CONTROL 

INTER- 

MONITORING; 

PLANNING/DECISION 

OPERABILITY 

PLANNING/ 

CONTROL 

MAKING; AUTHORING 

DECISION  MAKING 

PRESENTATION 

MONITORING/ 

CONTROL 

AUTHORING 

MONITORING 

AUTHORING 

PRESENTATION 

CONTROL 

DIAGNOSIS/ 

PROBLEM 

FINDING; 

PRESENTATION 
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SW  DAILY  QUARTERLY  ANNUAL 

TYPE  TASKS  TASKS  TASKS 


PLANNING/ 

DECISION 

MAKING 

ST  DIAGNOSIS/ 

PROBLEM 

FINDING 

AUTHORING 

PRESENTATION; 

DIAGNOSING/ 

PROBLEM 

FINDING 

WP  AUTHORING  MONITORING 

PRESENTATION  CONTROL 
AUTHORING 
PRESENTATION; 

COMMUNICATION 

AUTHORING 

PRESENTATION 

AUTHORING 

PRESENTATION 

AUTHORING 

PRESENTATION 

AUTHORING 

PRESENTATION 

AUTHORING  MONITORING 

PRESENTATION  CONTROL 


AWARDS  AND 
DECORATIONS ; 
AUTHORING 
PRESENTATION 


ALL 

AUTHORING 

PRESENTATION 


Appendix  11:  Perceived  Hourly  Usage  of  Software  per  Week 


HRS 


sw 

PRODUCT 

CRIT 

USED 

TYPE 

NAME 

PROD# 

UNIT 

OFFICE 

WK 

CO 

COORDINATOR 

2 

CCCCC 

LLL 

2.0 

SMART  TERM 

240 

1 

CCCCC 

LLL 

1.0 

Z  STEM 

3 

AAAAA 

III 

100.0 

DB 

CONDOR 

1 

BBBBB 

FFFF 

25.0 

D  BASE  I 11+ 

2 

BBBBB 

FFFF 

10.0 

DBASE 

II ; DBASEII I • 

1 

BBBBB 

HHHME 

35.0 

DBASE  III 

1 

BBBBB 

HHHME 

35.0 

30.0 

2 

BBBBB 

HHHMS 

10.0 

3 

AAAAA 

IIIII 

1.0 

DBASE  III+ 

2 

BBBBB 

FFFFPA 

20.0 

MICROX 

1 

BBBBB 

HHHCDI 

80.0 

PARTS  MASTER 

1 

BBBBB 

HHHCX 

8.0 

2 

BBBBB 

HHHCDI 

80.0 

GR 

CHART 

1 

BBBBB 

FFFFPA 

30.0 

AAAAA 

GGGGG 

15.0 

2 

BBBBB 

FFFF 

2.0 

AAAAA 

EE 

30.0 

3 

BBBBB 

HHHCR2 

0.5 

HARVARD 

1 

CCCCC 

DDD 

80.0 

GRAPHICS 

100.0 

5.0 

2 

CCCCC 

FFZ 

20.0 
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HRS 

SW  PRODUCT  CRIT  USED 


TYPE 

NAME 

PROD# 

UNIT 

OFFICE 

WK 

DDD 

2.0 

3 

CCCCC 

LL 

150.0 

FFFA 

4.0 

FFZ 

2.0 

FFF 

2.0 

IT 

ABILITY 

1 

CCCCC 

FFFA 

10.0 

ENABLE 

1 

AAAAA 

III 

150.0 

EE 

1000.0 

40.0 

2 

CCCCC 

FFF 

40.0 

DDD 

20.0 

AAAAA 

IIIII 

1.0 

3 

CCCCC 

DDD 

1.0 

OT 

QBS 

2 

CCCCC 

DDD 

5.0 

PL 

BASIC 

3 

AAAAA 

GGGGG 

1.0 

PM 

TIMELINE 

3 

CCCCC 

DDD 

5.0 

SS 

LOTUS  123 

1 

BBBBB 

HHHCR2 

1.5 

FFFF 

12.0 

CCCCC 

FFZ 

15.0 

AAAAA 

IIIII 

13.0 

2 

CCCCC 

FFZ 

10.0 

AAAAA 

GGGGG 

5.0 

III 

50.0 

EE 

300.0 
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sw 

TYPE 

PRODUCT 

NAME 

CRIT 

PROD# 

UNIT 

OFFICE 

HRS 

USED 

WK 

3 

CCCCC 

FF 

1.0 

AAAAA 

EE 

20.0 

QUATRO 

3 

CCCCC 

FF 

1.0 

SUPERCALC 

III 

3 

CCCCC 

FF 

1.0 

VP  PLANNER 

1 

CCCCC 

FFG 

10.0 

3 

CCCCC 

FF 

1.0 

ST 

BASS 

3 

CCCCC 

LLL 

5.0 

MICROSTAT 

1 

CCCCC 

FFZ 

10.0 

3 

CCCCC 

FFZ 

5.0 

POWERPACK 

3 

CCCCC 

LLL 

5.0 

WP 

MULT I MATE 

1 

CCCCC 

FF 

15.0 

PEACHTEXT 

1 

CCCCC 

FF 

15.0 

AAAAA 

EE 

45.0 

3 

AAAAA 

EE 

.  75.0 

VOLKSWRITER- 

3 

1 

CCCCC 

FF 

15.0 

WORDPERFECT 

1 

CCCCC 

DDD 

30.0 

WORDSTAR 

1 

BBBBB 

HHHMS 

20.0 

CCCCC 

FF 

15.0 

FFF 

15.0 

2 

BBBBB 

HHHCR2 

0.5 

CCCCC 

LL 

750.0 

FFFA 

4.0 
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sw 

TYPE 


HRS 

PRODUCT  CRIT  USED 

NAME  PROD#  UNIT  OFFICE  WK 


WRITE  ONE  1  CCCCC  FF  15.0 


WRITESOFT 


3 


BBBBB 


FFFFPA 


20.0 


Appendix  12:  User  Comments 


UNIT 


BBBBB 


OFFICE  COMMENTS 


HHHC  IT’S  MUCH  EASIER  FROM  A  MANAGER’S 
STANDPOINT,  TO  ORDER  ALL  THE 
SOFTWARE  WE  THINK  WE  MAY  USE  IN  THE 
FUTURE.  GENERALLY,  ALL  SOFTWARE 
REQUIREMENTS  WERE  BASED  ON  AN 
ASSESSMENT  OF  FUTURE  NEEDS,  WHAT 
WAS  ON  THE  STANDARD  ZENITH 
CONTRACT,  AND  THE  PRICE  OF  THE 
SOFTWARE.  NO  REAL  FORMAL 
REQUIREMENTS  ANALYSIS  WAS 
CONDUCTED. 

HHHCDI  PLAN  TO  UPDATE  MICROX  TO  ELIMINATE 
MULTIPLE  DISKS  (PLAN  TO  CONSOLIDATE 
INTO  ONE  DISKETTE) 

HHHCR2  MAY  USE  BOING  CALC 

HHHCX  SOFTWARE  STORE  -  OBTAIN  SOFTWARE 
FOR  BASE;  CUSTOMERS  SUBMIT 
REQUIREMENT;  STORE  PROCESS 
REQUIREMENTS;  CONTRACTING  BUYS  (MR 
XXXXXX ) ;  S.W.  STORE  CAN  BUY  UP  TO 
$5000  DIRECTLY;  FROM  STORES  OFF 
BASE  THROUGH  A  BUYER  -  PURCHASE 
AGREEMENT  (4  COMPANIES);  OPEN  SINCE 
1986  -  STARTED  WITH  40  ITEMS;  UP  TO 
OVER  200  LINE  ITEMS. 

HHHME  SOFTWARE  HAS  SATISFIED  NEED  TO 

TRACK  EQUIPMENT,  INVENTORY,  SERVICE, 
AND  SCHEDULE/SERVICE 

TECHNICIANS;  TRACKS  TRANSACTIONS  AND 
MAKES  USE  OF  MANPOWER ; TRACKS 
EXPENDITURES  BY  ORGANIZATIONS 
COMPUTER  TRAINING  IS  DIFFICULT  TO 
OBTAIN.  THIS  PREVENTS  MORE  PEOPLE 
FROM  GAINING  MAXIMUM  USE  OF  THE 
SYSTEMS. 

HHHMS  COMPUTER  TRAINING  IS  DIFFICULT  TO 
OBTAIN.  THIS  PREVENTS  MORE  PEOPLE 
FROM  GAIN  MAXIMUM  UTILIZATION  FROM 
THE  SYSTEM  AND  THE  SOFTWARE. 
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UNIT 


OFFICE 


COMMENTS 


FFFF  WILL  BE  USING  LOTUS  123  MORE  NOW 
THAT  WE  HAVE  A  NEW  SINGLE  SHEET 
FEED  PRINTER  -  ESTIMATE  14  HOURS 
PER  WEEK 

FFFF  PEOPLE  ARE  ENTHUSIASTIC  ABOUT 

SOFTWARE;  NEW  PEOPLE  ARE  INTIMIDATED 
AT  FIRST 

CCCCC  LL  WP:  INTEROPERABILITY  IS  A 

PROBLEM;  HARVARD  GRAPHICS  IS  VERY 
SUCCESSFUL.  INTEROPERABILITY  MAJ 
IS  STILL  A  PROBLEM;  EMULATORS 
USED  CONTINUOUSLY 
NEED  MORE  GUIDANCE  WITHOUT 
STIFFLING  INNOVATION;  NEED  TO  EVOLVE 
STANDARDS;  DO  NOT  IMPOSE  STANDARD; 


29  FEB  88  XXXXXXXXXXXXX ;  TRIED  TO 
GET  STAFF  SC  SUPPORT  BUT  WAS 
REFUSED  FOR  REQUIRMENTS 
ANALYSIS;  EMULATORS  DOES  MAINFRAME 
CONNECTIVITY,  DOES  NOT  ESTABLISH 
BACKWARD  COMPATIBILITY  (BURROUGHS) 
AND  INTEROPERABILITY,  3  DIFFERENT 
EMULATORS,  NO  STANDARD; 

LLL  AQISITION  PROCESS  -  FM  3215  JUSTIFY, 
SOLE  SOURE  LETTER  AFSC  FM  36, 
PURCHASE;  WISH  A  SYSTEM  BE  DEVISED 
TO  OBTAIN  SW  DECISION  AT  LOWEST 
LEVEL  POSSIBLE  -  USERS  MAKE  THE 
BEST  REQUOIREMENTS  ANALYSIS  - 
CURRENT  REQUIREMENTS  COME  FROM  TOP 

FF  MOST  SW  SELECTED  DUE  TO  COURSE 

REQUIREMENTS; EMPHASIS  IS  ON 
TEACHING  STUDENTS  AND  RESEARCH;  COST 
EFFECTIVENESS  IS  FACTOR; JUST 
PURCHASED  10  COPPIES  OF  DBASE  III+ 

( EASY  TO  LEARN ) ;  TRY  TO  GET  SYSTEMS 
COMPATIBLE;  MOST  WP  AND  SS  DONE  ON 
BURROUGHS  DUE  TO  HARDWARE 
CONSTRAINTS;  ONLY  12  Z248S  AVAILABLE 
TO  FACULTY ;FFF  -  LTCOL  XXXXXXX  ; DDD 
LTCOL  XXXXXXX 
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UNIT 


OFFICE 


COMMENTS 


FFG  AWKWARD;  CURRENTLY  A  GRAD  STUDENT  IS 
DEVELOPING  A  PROGRAM  USING  DBASE 
III  TO  ACCOMPLISH  THE  MANAGEMENT 
TASKS  PERFORMED  BY  VP  PLANNER 
CCCCC/SC  KEEPS  TRACK,  INSTALLS, 

MAINTAINS  ALL  EQUIPMENT;  BUT  THEY 
DO  NOT  PERFORM  APPLICATIONS 
PROGRAMMING  FOR  USERS;  THIS  FORCES 
USERS  TO  LOOK  FOR  THEIR  OWN  SW  AND 
APPLICATIONS;  WOULD  LIKE  SC  TO  HELP 
DEFINE  REQMNTS  AND  SELECT/DEVELOPE 
APPROPRIATE  SW;  VP  PLANNER  ACQUIRED 
TO  ACCOMPLISH  MGT  OF  PC-BASED  GRAD 
STUDENT  DATABASE;  THIS  STREAMLINED 
ACCESS  TIMES  AND  REPORTS  GENERATION 
TIMES;  HOWEVER,  DATA  ENTRY  STILL 
CUMBERSOME  AND  SLOW 

FFF  CURRENT  POLICY  IS  TO  TRY  TO  PROVIDE 
SET  OF  TOOLS  STUDENTS  CAN  TAKE  AND 
LEAVE  WITH  READILY  AND  AT 
REASONABLE  COST;  PC  SW  CAN  HELP  MEET 
THIS  GOAL;  NO  EFFICIENT  USE  OF  WP  DUE  TO 

LACK  OF  HW  SUPPORT; LAST  YEAR 
TURBOPASCAL  WAS  ONE  OF  TOP  3  PKGS  - 
SW  ENVIRONMENT  CHANGES  RAPIDLY;  SW 
SUPPORT  FOR  TEXTBOOKS  IS  CRITICAL 
FACTOR;  GET  INVENTORY  SUMMARY  FROM 
LTCOL  XXXXXXX  OR  LTCOL  XXXXXXXXXXX 

FFFA  STUDENTS,  STAFF  WOULD  RESULT  IN 

BETTER  REQUMNTS  ANALYSIS/USE  DOWN 
THE  ROAD,  AF  WIDE; 

BUY  OFF  GOVT  CONTRACT  SOLEY  BECAUSE 
OF  COST,  NOT  BECAUSE  OF  REQUMNTS 
(ITS  EASIER  TO  BUY  EVERYTHING  UP 
FRONT  AND  JUSTIFY  LATER);  PEOPLE 
BUYING  PERSONAL  SW  TO  MEET  MISSION 
REQUMNTS;  GOVT  SW  IS  INADEQUATE  AND 
STAYS  ON  SHELF;  CCCCC/SC  IS  A 
HINDERANCE;  SW  ON  GOVT  CONTRACT  NOT 
UPGRADEABLE;  CCCCC  MGT  SHOULD  FOCUS 
ON  FOLLOWING,  NOT  LEADING  SW 
TESTING/EVAL;  SHOULD  SERVE  AS 
ACADEMIC  EVAL  FACILITY  FOR  NEW  SW 
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UNIT 


OFFICE 


COMMENTS 


MOST  SW  IS  PRIVATELY  OWNED 
SW;  PEOPLE  NOT  FREE  TO  DETERMINE 
THEIR  SW  NEEDS;  THEY  ARE  FORCED  TO 
TAKE  WHAT  IS  GIVEN;  ACQ  PROCESS 
IS  LONG  AND  COSTLY;  TOO  MUCH 
FOCUS  ON  STANDARDIZATION;  THIS  DOES 
NOT  ENHANCE  OUR  MISSION  REQUMNTS , 

E.G.  ENABLE  WAS  NOT  GOOD  SUBSTITUTE 
FOR  DBASE  III;  WORDSTAR4  (PERSONAL 
CY)  MUCH  BETTER  THAN  WORDSTAR,  BUT 
I  CAN’T  GET  FORMALLY  SINCE  NOT  ON 
GOVT  CONTRACT 

FFZ  NEED  TO  STREAMLINE  BUYING  OF 

SW;  UNITS  NEED  MORE  AUTONOMY  WHEN 
DECIDING  WHAT  SW  SHOULD  BE 
PURCHASED;  STANDARD  CONTRACT  TOO 
RESTRICTIVE;  ORGN  SHOULD  BE  ABLE  TO 
BUY  THE  RIGHT  TOOL  FOR  JOB,  NOT  TRY 
TO  FIT  STANDARD  CONTRACT  SW  TO  JOB 
IT  WAS  NOT  DESIGNED  TO  DO;  MAYBE  WE 
COULD  SELECT  SW  BASED  ON  ITS 
TRANSPORTABILITY 
MANY  SW  WERE  DRIVEN  BY  PRIOR 
MAINFRAME  APPLICATIONS;  PC 
APPLICATIONS  MUCH  EASIER  TO  USE  IN 
CLASSROOM  ATMOSPHERE 

FFF  NOT  ABLE  TO  IDENTIFY  APPROPRIATE 

SW;  INITIALLY,  AUTOMATION  WAS  DONE 
WITH  PRIVATE  HW  AND  SW;  WHEN  ZENITH 
WAS  ACQUIRED,  ZENITH  SW  WAS 
GATHERED 

MORE  ( SCTC  AT  MISSION  LEVEL);  BY 
PUTTING  OUT  FREE  ACCESS  COMPUTERS 
AND  SW,  MGT  AND  CONTROL  IS  A 
PROBLEM;  WORDSTAR  -  LIMITED  BY 
CAPABILITY  OF 

TRAN  S  PORT AB I L I TY/ 1 NTEROPERAB I L I T Y ; 
ENABLE  -  TEXT  PRODUCTION 
LIMITATIONS/LESS  EFFICIENT 
WORDPROCCESSOR;  NEED  TO  REKEY  INFO; 

NO  IMPORT  CAPABILITY 

NO  INTEROPERABILITY;  HARVARD  GRAPHICS 
NOT  ENOUGH  PREDEFINED  SYMBOLS;  NO 
GRAPHICS  LIBRARY/SLOW  PRINTING 
PROCESS;  NEEDS  WERE  IDENTIFIED  IN 
ADVANCE,  BUT  WE  WERE  NOT  ABLE  TO  BUY 
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UNIT 


OFFICE 


COMMENTS 


DDD 


1 ) IS  NEED  FOR  INTEGRATION  OF  SW/HW 
SYSTEMS  TO  REDUCE  DUPLICATION  OF 
EFFORT;  STORED  INFO  USED  BY  DIFFERENT 
DEPTS  SHOULD  NOT  HAVE  TO  BE 
RECREATED,  BUT  ANY  SUCH  SYSTEM  MUST 
INDIVIDUAL  TAILORING  TO  MEET 
REQUIREMENTS;  2)  NEED  A  CCCCC  AGENCY 
WITH  SW  LIBRARY;  HANDS  ON  EVAL  BY 
USERS  (WITHIN  CCCCC);  CENTRAL 
REPOSITORY/SITE  LISCENCE  AGREEMENTS 
THIS  MAY  SPEED  ACQUISITION,  USE 
AVAILABILITY,  AND  KNOWLEDGE 
OF  PRODUCTS;  WOULD  SAVE  MUCH  TIME 
AND  MONEY 

HARVARD  GRAPHICS  IS  USED  75%  OF 
EACH  WORK  DAY.  ALL  SOFTWARE 
REQUIREMENTS  ARE  LIMITTED  BY  THE 
AVAILABILITY  OF  MACHINES;  WE  ONLY 
HAVE  2  Z-248 ’ S  AVAILABLE.  MOST 
WORK  IS  DONE  ON  THE  BURROUGHS 
SYSTEM,  WHICH  DOES  NOT  ALLOW 
INTEROPERABILITY  WITH  THE  Z-248 ’S. 
ENABLE  AND  ZSTEM  ARE  ONLY  USED  1% 

OF  THE  TIME  DUE  TO  THIS  LIMITATION. 
USE  SOFTWARE  UNIQUE  TO  PARTICULAR 
JOB;  SC  AND  FORMAL  REQMTS  TOO 
RESTRICTIVE;  PRIVATE  PROPERTY 
USED;  MANY  TASKS  ACCOMPLISHED  AT 
HOME,  THUS  PERSONAL  SW  AQUIRED 
INDIVIDUALLY  IS  USED  - 
QBS , SLAM , STAT  PKGS,WORD 
PROCESSORS; CONFLICT  BETWEEN  ( GFE ) 
FORMAL  VS  (PERSONNEL)  PRIVATE  SW 
THE  DRIVING  FORCE  BEHIND  OUR 
REQUIREMENTS  IS  THE  NEED  TO  HAVE 
SOFTWARE  THAT  IS  COMPATIBLE  WITH 
WHAT  PROFESSORS  ARE  USING  AT  HOME 
(THEY  ARE  ALLOWED  TO  WORK  THERE 
WHEN  NOT  TEACHING). 

IN  GENERAL,  WE  ARE  GOING  TO  AN  M-S 
DOS  BASED  SYSTEM.  IN  THE  ACADEMIC 
ENVIRONMENT,  WORK  IS  DONE  AT  HOME 
AND  AT  THE  OFFICE;  COMPATIBILITY 
BETWEEN  HOME  AND  OFFICE  SYSTEMS 
BECOMES  MORE  OF  A  NECESSITY;  AS  AN 
ACADEMIC  INSTRUCTOR,  ACADEMIC 
PAPERS  ARE  SUBMITTED  IN  WORD 
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UNIT 


OFFICE 


COMMENTS 


AAAAA 


PERFECT  FORMATTED  DISKETTES.  THE 
SYSTEMS  NEED  TO  BE  MORE 
STANDARDIZED/COMPATIBILITY  WITH  THE 
REST  OF  THE  ACADEMIC  COMMUNITY. 

WE  ARE  STRUGGLING  WITH  COMPUTER 
NEOPHYTES;  NOVICE  USERS  STILL  DO  NOT 
KNOW  WHAT  SW  IS  AVAILABLE  FOR 
STREAMLINING  JOBS;  USERS  MUST  GET 
SMARTER  IN  PC  KNOWLEDGE  SO  THEY  CAN 
BETTER  DEFINE  THEIR  SW  REQUIREMENTS 
DBASE  III  +  REQUIREMENTS 
ANALYSIS; INTENDED  AS  AN  INSTRUCTION 
AIDE 

GGGGG  VAST  MAJORITY  OF  SW  CAME  WITH 
SYSTEM  VIA  STANDARD  ZENITH 
CONTRACT;  GOVT  SW  IS  SECOND  HAND 
COMPARED  TO  COMMERCIALLY  AVAILABLE  SW 

III  LOT  OF  PUSH  ON 

STANDARDIZATION;  SHOULD  BE  LESS  ON 
STANDARDIZATION  AND  MORE  ON 
APPLICATIONS,  USER  NEEDS, 

EXCHANGE AB I L I T Y/ I NTERCH ANGEAB I L I T Y 
OF  DATA 

IIIII  TRAINING  AVAILABILITY  IS  KEY  FACTOR  IN 
SELECTING  SW;  TYPE  OF  PEOPLE  IS  ALSO 
FACTOR;  YOUNGER  PEOPLE  MORE  APT  TO 
CHANGE;  ONCE  USERS  LEARN  ONE  SYSTEM, 

DO  NOT  WANT  TO  CHANGE;  COMPATABILITY 
OF  SYSTEMS  AND  SW  WITH  OTHER  ORGS  IS 
ANOTHER  KEY  FACTOR;  WHEN  WE  GET  MORE 
PC’S  AND  WORK  STATIONS,  WE  PLAN  TO 
LOOK  AT  MORE  SW  TO  FACILITATE 
COMMUNICATIONS  AND  EMAIL 

II  THE  KEY  IS  "USERS  DO  NOT  HAVE 

ENOUGH  INPUT  INTO  DETERMINING  THEIR 
REQUIREMENTS  OR  SELECTING 
SOFTWARE".;  THE  PRODUCTS  ARE 
EXCELLENT  AND  RELIABLE.;  "MAYBE  A 
TRIAL/SAMPLE  USE  WOULD  HELP." 

THE  KEY  IS  "USERS  DO  NOT  HAVE 
ENOUGH  INPUT  INTO  DETERMINING 
THEIR  REQUIREMENTS  OR  SELECTING 
SOFTWARE" .; THE  PRODUCTS  ARE 
EXCELLENT  AND  RELIABLE .; "MAYBE  A 
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UNIT 


OFFICE 


COMMENTS 


TRIAL/SAMPLE  USE  WOULD 
HELP. " ; CONSULTED  USERS  AND 
ORGANIZATIONS  TO  SEE  WHAT  SOFTWARE 
PRODUCTS  APPROPRIATE  FOR  MISSION 
REQUIREMENTS. 

IN  ACQUIRING  SOFTWARE,  USER'S  NEEDS 
ARE  THE  DRIVING  FORCE.  SOFTWARE 
NOT  DEFINED  BY  USES  IS  SELDOM  USED. 
ISSCO  GRAPHICS  IS  AN  EXAMPLE  OF  A 
POORLY  DEFINED  REQUIREMENT. 
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Appendix  13:  The  Use  of  Q&A  DBMS  for  Data  Analysis 
General 

Q&A  is  a  flat  file  data  base  management  system,  much  like 
the  popular  Dbase  III  software  package.  In  addition  to 
allowing  the  user  to  design  a  data  base,  input  and 
manipulate  data,  and  generate  reports,  the  software  package 
also  contains  utilities  for  exchanging  information  with 
several  popular  data  base  management  systems,  spreadsheets, 
and  ASCII  text  formats.  Q&A’s  strength  lies  in  it’s  ability 
to  handle  both  recurring  reports  necessary  for  generation  as 
well  as  ad  hoc  queries  (through  the  use  of  its  natural 
language  interface  known  as  the  Intelligent  Assistant). 
Because  of  these  features,  along  with  the  system’s  ease  of 
use,  interoperability,  and  data  transportability,  Q&A 
appeared  as  a  likely  choice  for  organizing  data  generated 
for  this  study.  This  section  explains  the  approach  used  in 
designing  the  data  bases  used  for  literature  and  data 
analysis,  the  data  input  procedures,  and  the  analysis 
methods . 

Data  Base  Design 

Two  data  bases  were  designed  for  ease  of  analysis.  The 
first  data  base,  LITREV.DTF,  consisted  of  technical 
literature  used  in  Chapter  II.  The  second  data  base, 
DBFILE.DTF  contained  fields  representative  of  the  survey 
questions  listed  in  Appendix  1.  Figures  15  and  16  display 
data  input  screens  developed  for  the  respective  data  bases. 
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The  approaches  used  to  design  each  data  base  were 
similar,  and  involved  two  main  steps  including  1) 
determining  the  desired  outputs,  and  2)  determining  the 
inputs  necessary  to  obtain  the  desired  outputs. 

The  first  step  was  to  determine  what  output  was 
necessary  for  analysis.  In  the  case  of  the  LITREV.DTF  data 
base,  the  desired  output  was  a  listing,  by  category,  of  key 
points  in  documents  reviewed.  Thus,  when  analyzing  all  the 
available  literature  on  design  considerations,  the  ability 
to  extract  similar  comments  from  reports  and  compile  them 
in  one  list  was  considered  a  necessary  requirement.  The 
rest  of  the  data  base  was  designed  around  this  key 
ingredient . 

For  the  DBFILE.DTF  data  base,  the  desired  output  was  a 
series  of  reports  necessary  to  answer  the  research  questions 
stated  in  Chapter  I.  The  determining  factor  in  these 
reports  was  the  need  for  information  sorted  by  a  series  of 
different  fields,  including  software  type,  critical  software 
products,  organizations,  and  office  symbols. 

Once  the  desired  outputs  were  determined,  the  second 
step,  determination  of  inputs  necessary  to  obtain  the 
outputs  was  undertaken.  In  the  case  of  the  literature 
review  data  base,  the  bibliographical  data  was  necessary 
for  documentation  as  well  as  traceability  of  the  comments. 

In  addition,  a  "key  words"  field  was  added  to  allow  the 
ability  to  sort  comments  based  on  the  desired  topics. 
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The  survey  data  base  employed  the  survey  questions  as 
input  fields.  To  facilitate  analysis,  the  input  phrases 
were  standardized  prior  to  data  entry.  Help  facilities  were 
designed  into  the  data  base  to  allow  the  data  entry  operator 
to  determine  which  phrases  to  use  (i.e.,  CO  for 
communications  software,  Y  for  yes,  etc.).  This 
standardization  of  data  entry  allowed  easier  sorting  during 
reports  generation  for  analysis. 

Data  Input  Procedures 

For  the  LITREV.DTF  data  base,  data  input  was  relatively 
straightforward.  The  bibliographical  information  was 
entered  in  the  appropriate  fields,  as  were  comments  from  the 
articles  reviewed.  Within  each  record,  literature 
categories  were  noted  in  the  "key  words"  field.  For  areas 
where  more  than  one  key  word  was  appropriate  (i.e.,  Design 
Considerations,  User  Involvement)  the  key  words  were 
separated  by  a  semi-colon.  This  feature  allowed  T-he  same 
data  to  be  generated  in  reports  which  asked  for  either  key 
word . 

The  DBFILE.DTF  data  base  input  involved  more  detailed 
input  procedures.  Originally,  data  was  intended  for  input 
directly  the  way  it  appeared  on  the  survey  questionnaire. 
However  creation  of  one  record  for  each  individual  surveyed 
proved  unfeasible  because  of  the  number  of  software  products 
mentioned  by  each  respondents,  and  the  length  of  some 


comments.  To  facilitate  an  accurate  account  of  each  field, 


records  were  created  based  on  each  software  product 
mentioned  by  the  individuals.  Thus,  if  a  person  identified 
thirty  software  products,  thirty  records  were  created  with 
that  individual's  name,  organization  and  office  symbol.  The 
copy  command  allowed  easy  input  of  redundant  information. 

In  addition,  if  comments  extended  beyond  the  defined  field 
length,  another  record  (stripped  of  all  previous  data  except 
name  and  organization),  was  created.  As  a  result  of  the  way 
input  criteria  were  defined,  241  records  were  generated  for 
29  respondents  in  the  DBFILE.DTF  data  base. 

Data  Analysis  Methods 

Analysis  of  both  literature  and  survey  data  was 
streamlined  once  the  data  base  reports  were  generated.  For 
example,  when  looking  for  important  points  to  mention  in 
design  considerations,  a  list  of  comments  and  observations 
was  readily  examined.  In  some  cases,  quotes  or  remarks  were 
directly  imported  into  a  word  processor  file,  eliminating 
the  need  for  input  duplication.  Survey  data  was  arranged  in 
such  a  fashion  as  to  allow  easy  observation  of  trends,  based 
on  the  way  data  was  sorted.  For  example,  critical  software 
products  were  much  easier  to  categorize  and  count  when 
arranged  by  software  type  in  alphabetical  order.  Like  the 
literature  review  information,  the  reports  were  quickly 
converted  to  word  processing  text.  Appendices  2  through  12 
were  generated  by  Q&A  and  saved  as  MS-DOS  files  for 
integration  into  one  file. 
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Summary 


The  Q&A  software  demonstrated  it’s  effectiveness  by 
allowing  easy  manipulation  of  information  required  for 
analysis.  By  designing  reports  based  on  research 
objectives,  the  literature  review  and  the  analysis  of  survey 
data  were  easily  accomplished. 
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LITERATURE  REVIEW  DATA  BASE 

AUTHOR ( S ) : 

TITLE: 

PERIODICAL: 

COMMENTS : 

REMARKS : 


KEY  WORDS: 


Figure  15.  LITREV.DTF  Data  Base  Design 
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SURVEY 

DATA  BASE 

UNIT:  TEST  CASE 

SIZE: 

OFFICE_SYMBOL : 

NAME /RANK: 

SW_TYPE: 

NO_COPIES: 

TOTAL_COST : 

PRODUCT_NAME : 

UNIT_COST : 

CRITICAL_PRODUCT# : 
PRIMARY  TYPE_OF_USERS : 
HOW  ACQUIRED: 
SOURCES_CONSULTED : 

PUBLICATIONS_CONSULTED : 

HOW_NEED_WAS_DETERMINED : 

INTENDED_TASKS : 

TASKS_STREAMLINED : 

TASKS_NOT_STREAMLINED : 

SATISFACTION?: 

PRODUCT  NAME : 

COMPARISON?: 

REASON_FOR_CHOICE : 

DAILY_TASKS: 

QUARTERLY_TASKS : 

ANNUAL_T AS  KS : 

HRS_USE/WK: 

COMMENTS : 

Figure  16.  DBFILE.DTF  Data  Base  Design 
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The  Purpose  of  this  study  was  to  determine  how  Air 
Force  Organizations  selected  Personal  Computer  (PC)  software, 
to  determine  the  effectiveness  of  standard  PC  software 
acquisition  practices ,  and  to  determine  if  better  methods 
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office  tasks.  As  a  remedy  for  a -lack!-  of  sufficient  guidance, 
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need  to  fit  the  software.  Data  suggested,  however,  that  at 
times  this  resulted  in  less  than  optimum  use  of  the  software. 
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